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Abstract 


The Next Generation Air Transportation System ( NextGen ) concept for 2025 envisions the movemen t 
of large n umbers of people and goods in a safe, efficien t, and reliable manner. The NextGen will remove 
many of the constraints in the current air transportation system, support a wider range of operations, and 
deliver an overall system capacity up to 3 times that of current operating levels. In order to achieve the 
NextGen vision, research is necessary in the areas of surface traffic optimization, maximum runway 
capacity, reduced runway occupancy time, simultaneous single runway operations, and terminal area 
conflict prevention, among others. 

The National Aeronautics and Space Administration (NASA) is conducting Collision Avoidance for 
Airport Traffic (CAAT) research to develop technologies, data, and guidelines to enable Conflict 
Detection and Resolution (CD&R) in the Airport Terminal Maneuvering Area (ATM A) under current and 
emerging NextGen operating concepts. The term ATMA was created to reflect the fact that the CD&R 
concept area of operation is focused near the airport within the terminal maneuvering area. In the 
following, an initial concept for an aircraft-based method for CD&R in the ATMA is presented. This 
method is based upon previous NASA work in CD&R for runway incursion prevention, the Runway 
Incursion Prevention System (RIPS). 


1 Introduction 

By 2025, U.S. air traffic is predicted to increase significantly, yet the current air traffic management 
system may not be able to accommodate this growth. In response to this challenge, a consortium of 
industry, academia, and government agencies have proposed a revolutionary new concept for U.S. 
aviation operations, termed the Next Generation Air Transportation System or “NextGen” [JPDO, 2004]. 
Emerging NextGen operational concepts represent a different approach to air traffic management and as a 
result, a dramatic shift in the tasks, roles, and responsibilities for the flight deck to ensure a safe, 
sustainable air transportation system. 

To support the operational goals - the “vision” - of NextGen, the Joint Planning and Development 
Office (JPDO) has published a Concept of Operations (ConOps) [JPDO, 2010] and a research and 
development plan [JPDO, 2007] to develop the technologies that it considers vital to reach the NextGen 
goals. While this vision is not necessarily shared by all nor is it the only way to achieve NextGen, it does 
illustrate many of the challenges to achieving a NextGen operating environment. In this report, the term 
Airport Terminal Maneuvering Area (ATMA) was created to reflect the fact that the CD&R concept area 
of operation is focused near the aiiport within the terminal maneuvering area. In particular, key 
challenges associated with the NextGen ATMA include: 

• Trajectory-based operations that use closely spaced arrivals and departures to enable aiiport safety 

and capacity, independent of the visibility and weather conditions. 

• Arrival and departure procedures that shift away from rigid, clearance-based air traffic control 
processes to flexible, adaptive air traffic management principles utilizing reduced spacing buffers, 
more runways, and innovative merging and spacing 4-dimensional (4-D) trajectory operations. 

• Automated surface management systems that utilize dynamic algorithms to calculate the most 
efficient movement of all surface traffic to increase efficiency [Cheng et al., 2003]. Pilots will be 
required to comply with 4-D taxi clearances, dictating that aircraft arrive at specific locations 
within specific time windows. 

• Potential pilot responsibility for “separation” from other aircraft, during all phases of flight, 
regardless of visibility conditions. 
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Proactive safety layers are being designed to enable these emerging NextGen operational concepts. 
Automation to manage, assist, and even conduct these procedures and operations will be developed. 
Nonetheless, it is imperative to have a conflict detection system that is an integral part of and integrated 
with, the emerging NextGen technologies to provide an additional protective layer should these proactive 
measures unforeseeably fail. This critical need is recognized under the JPDO vision in its research and 
development plan [JPDO, 2007]. 

This paper presents a concept for an aircraft-based method for CD&R in the ATMA. A concept and 
technical description is given for CD&R algorithms that detect potential conflicts in the ATMA during 
runway, taxiway, and low altitude operations and generate indications and alerts and possibly resolution 
advisories for display to the pilot. Note that in this paper, a conflict is defined as a condition that can lead 
to a collision if no avoidance action is taken. This version updates previously published work [Green et 
al., 2009] with the revisions summarized in the document revision history. 

2 Background 

Relevant research and systems for CD&R in the ATMA are discussed. 

2.1 Runway Incursions 

The harmonized Federal Aviation Administration (FAA)/International Civil Aviation Organization 
(ICAO) definition for runway incursion [FA A, 2009a], adopted on October 1, 2007, is: 

Any occurrence at an aerodrome involving the incorrect presence of an aircraft, vehicle, or person on 
the protected area of a surface designated for the landing and take-off of aircraft. 

Runway incursions are a serious aviation safety hazard. The National Transportation Safety Board 
continues to have improving runway safety on its most wanted list of transportation safety improvements 
for aviation [NTSB, 201 1], The FAA is committed to reducing the severity, number, and rate of runway 
incursions by implementing a combination of guidance, education, outreach, training, technology, 
infrastructure, and risk identification and mitigation initiatives [FAA, 2011], Progress has been made in 
reducing the number of serious incursions - from a high of 67 in Fiscal Year (FY) 2000 to 6 in FY 2010. 
However, the rate of all incursions has risen steadily over recent years - from a rate of 12.3 incursions per 
million operations in FY 2005 to a rate of 18.9 incursions per million operations in FY 2010. [FAA, 201 1 
and FAA, 2009a] The worst aviation accident - 583 fatalities - was caused by a runway incursion in 
1977 when two fully loaded 747 airplanes collided on a runway at Tenerife airport. The accident 
occurred in low visibility (300 meters visual range) conditions. A departing aircraft crashed head-on into 
an aircraft taxiing in the opposite direction on the same runway. The present-day statistics and events are 
cause enough for alarm but, without proactive counter-measures, the increase in air traffic forecasted 
under NextGen could potentially result in catastrophic increases in runway incursion accidents. 

Numerous efforts have been launched by the FAA, industry, and others to reduce the frequency of 
runway incursions and the risk of runway collisions to meet the recommendations put forth by the NTSB 
[NTSB, 2000], These solutions include Airport Surface Detection Equipment Model X (ASDE-X), 
Airport Movement Area Safety System (AMASS); Final Approach Runway Occupancy Signal (FAROS); 
Runway Status Lights (RWSL); enhanced controller training; airport surface operations advisory 
circulars; improved airport markings and lighting; improved pilot education, training, and awareness; and 
revised pilot/controller communications phraseology. These efforts target improved awareness and 
enhanced surveillance, but do not include technology solutions for the flight deck. 
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Currently, no system is available (either ground or aircraft-based) that directly provides the flight 
deck with alerts of potential runway conflicts with other traffic. However, some flight deck-based ATMA 
situation awareness systems are available, including: 

• Honeywell International Inc. has developed an aircraft-based Runway Awareness and Advisory 
System (RAAS) [Honeywell, 2006]. RAAS uses Global Positioning System (GPS) position data 
and a database to provide aural-only advisories that supplement flight crew awareness of own 
aircraft position during ground operations and on approach to landing. RAAS does not, however, 
provide alerts of runway incursion conflicts with other traffic. 

• SafeRoute™, developed by Aviation Communication & Surveillance Systems, provides the pilot 
with an electronic map of the airport surface on an electronic flight bag, showing ownship and 
other aircraft positions. The system will also indicate when a runway is occupied by highlighting 
the runway on the display [Evans, 2007]. SafeRoute™ does not, however, detect and alert for 
conflicts between aircraft and vehicles. 

NASA- and FAA-sponsored research has also been conducted by Honeywell Aerospace and Sensis 
Corp. to transmit ASDE-X runway incursion alerts (which are optimized for Air Traffic Control (ATC)) 
to the flight deck [Hughes, 2007]. Additional research is needed to determine the effectiveness of 
providing the ATC-optimized ASDE-X alerts to the flight crew and data link requirements. 

Working cooperatively with NASA, Era Corporation has developed a conflict detection and alerting 
system, known as PathProx™, that detects potential runway conflicts and generates alerts for display to 
the flight crew [Cassell et al., 2003]. PathProx™ does not include the cockpit display device and is not 
commercially available at this time. 

Under NASA’s Aviation Safety Program, Synthetic Vision Systems Project, the Runway Incursion 
Prevention System (RIPS) was developed to address the growing problem of runway incursions as a 
significant contributor to the fatal aviation accident rate in commercial, business, and general aviation 
sectors [Jones et al., 2001, Jones, 2002, Jones, 2005, and Jones and Prinzel, 2006]. As part of this work, 
the Runway Safety Monitor (RSM) was conceived as a method of automated CD&R for approach, 
landing, and surface (runway) operations. This effort focused on flight deck technologies and alerting, in 
contrast to other agency and company initiatives. 

The Enhanced Traffic Situational Awareness on the Aiiport Surface with Indications and Alerts 
(SURF IA) application has been established by RTCA Special Committee 186 to reduce the likelihood 
and severity of runway incursions and collisions. Safety, performance, and interoperability requirements 
(SPR) [RTCA, 2010b] have been developed under SURF IA to increase flight crew situation awareness of 
the runway environment and facilitate an appropriate and timely response to potential conflict situations. 
As part of this effort, the FAA sponsored flight demonstrations, conducted by Aviation Communication 
and Surveillance System and Honeywell, to show the feasibility of implementing this technology. NASA 
also conducted research that was integrated into this effort. 

2.2 Low Altitude Air-to-Air Conflicts 

In today’s operations, the most notable airborne method of flight deck-based CD&R is provided by 
the Traffic Alert and Collision Avoidance System (TCAS). TCAS predicts a penetration to an aircraft’s 
airspace and provides associated alerts to the flight crew. TCAS has been developed and improved for 
over 25 years and has been very effective in reducing or eliminating airborne collisions. This system does 
have known limitations in the vicinity of airports and TCAS alerts are inhibited at low altitudes. 
Resolution Advisories are not issued below 1000 feet Above Ground Level (AGL) and audible Traffic 
Advisories are not issued below 500 feet AGL [FAA, 2000]. Research to date indicates that the use of 
TCAS may work for envisioned trajectory-based 4-D operations [Ivanescu et al., 2004], but the suitability 
of TCAS degrades in operations nearing the airport [Pritchett et al., 1995]. 
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RTCA SC-147, Traffic Alert and Collision Avoidance System, is addressing how to make TCAS 11 
more compatible within the National Airspace System and how to integrate ADS-B into the next 
Collision Avoidance System [RTCA, 2010a], In the area of collision avoidance, RTCA SC-147 is 
specifically chartered to: 

• make collision avoidance more compatible with routine operations in congested airspace, 
including busy terminal areas in the National Airspace System (NAS), now and out through the 
2025 time frame; 

• make appropriate use of ADS-B information in a future collision avoidance system (or next- 
CAS); and 

• reduce the radio frequency congestion at 1090 MHz. 

Since international harmonization of CAS equipment is essential, SC-147 will work collaboratively with 
EUROCAE Working Group 75 (WG75) and appropriate ICAO bodies. Many experts in ADS-B 
technology, a potentially important component of a future CAS, already support RTCA through Special 
Committee 186. Recommendations on the development of future collision avoidance systems are slated 
for delivery by September 2011 [RTCA, 2010]. 


2.3 Taxi Conflicts 

The NextGen concept proposes the use of ground-based automation to schedule surface traffic and 
generate 4-D taxi clearances to enable precise departure times and limited simultaneous runway 
occupancy [JPDO, 2010]. This move toward 4-D surface operations pushes the CD&R need beyond the 
runway and must include surface operations. Research has been initiated to determine the information 
display requirements for presentation of automated 4-D taxi clearances to the pilot and the ability of the 
pilot to comply with the 4-D clearances [Williams et al., 2006, Foyle et al., 2009, Prinzel et al., 2009, 
Shelton et al., 2009, Cheng et al., 2009, and Foyle et al., 2011]. The safety impact of following 4-D taxi 
clearances has not been determined, however; it is a concern that the pilot may be so focused on 
following 4-D clearances to meet scheduled arrival times that unintentional taxi conflicts could result. If 
this is the case, taxi conflict detection capability becomes critical. 

2.4 ATCAM Concept 

For emerging NextGen operating concepts, CD&R capabilities are desirable as the last of several 
proactive safety-enabling separation assurance layers. To provide a basis for this development and to 
begin research under CAAT, an initial concept for CD&R in the ATMA is proposed in the following as 
an extension of the RIPS work. This concept - Airport Traffic Collision Avoidance Monitor (ATCAM) - 
is described in the following sections. Also, the data communications to support this application are 
described to assess the feasibility of the concept, given current and projected equipage and current and 
NextGen operating environments. 

3 ATCAM Concept Description 

The goal of ATCAM is to detect potential traffic conflicts in the ATMA and generate flight deck- 
based indications, alerts, and possibly resolution advisories to provide sufficient awareness so that 
collisions are avoided. ATCAM operates at low altitudes near the airport without conflicting with TCAS, 
as well as on the runway and during taxi operations for multiple classes and equipage of aircraft and 
surface vehicles. 

ATCAM is comprised of three separate aircraft-based algorithms that rely on target state information 
that can be obtained from various sources: 
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1 . The Runway Safety Monitor (RSM) is designed to detect runway incursion conflicts and generate 
alerts and indications that provide the flight crew with sufficient awareness to take action to avoid a 
collision. RSM was developed in support of RIPS research and is retained as a core element of ATMA 
CD&R. Enhancements are planned for RSM based on current and emerging NextGen operational 
concepts and research findings. 

2. The Low Altitude Conflict Monitor (LACM) is designed to detect and alert for air-to-air conflicts 
at low altitudes near the aiiport. Indications are not currently generated for LACM. 

3. The Taxi Conflict Monitor (TCM) is designed to detect and alert for ground taxi conflicts 
anywhere in the airport movement and ramp areas. Indications are not currently generated for TCM. 

The three algorithms are separate and independent but are integrated and share data to increase the 
probability of detection for all possible conflicts during airport operations. RSM has been through 
extensive simulation and flight testing. LACM and TCM are less mature but have been evaluated in 
simulation studies. Results of those studies suggest further refinements to these algorithms. 

Ligure 1 is a high level flow chart depicting the process for ATCAM conflict detection including 
coordination and prioritization of indications and alerts in the event of multiple indications and alerts 
from the same or multiple algorithms. A description of this process follows. 

When the ownship is on the surface or at low altitude and new traffic data becomes available (see 
Section 4.0, ATCAM Data Communications Requirements), the RSM algorithm runs first to monitor 
other airborne or ground traffic for possible runway incursions. After RSM completes, either the LACM 
algorithm or the TCM algorithm is called depending on the position of the ownship. If the ownship is on 
the ground, TCM monitors possible conflicts with other aircraft or vehicles anywhere on the airport 
surface. If the ownship is airborne, LACM monitors possible conflicts with other airborne aircraft. 

It is possible for conflicts detected by TCM or LACM to overlap with RSM (i.e., a TCM/LACM 
conflict could also be a runway incursion) and conflicts can also occur that are not runway incursions. 
ATCAM resolves any differences between alerts issued by the algorithms and prioritizes the alert data for 
output. The alert data, or null data if no alerts, is then output for use by the flight deck aural and graphical 
displays (see Section 4.3, Output Data Requirements). 

This process of reading the ownship and traffic data, calling the conflict detection algorithms, 
coordinating and prioritizing indications and alerts, then outputting the indication and alert data is 
repeated approximately once per second. All algorithms are enabled by default but can be individually 
disabled. Each algorithm is implemented using the concept and technical approach that is optimal for the 
type of conflict being monitored. 

A high level description of the indication and alerting concept and algorithms is given in the 
following sections. The ATCAM concept will be updated as necessary to address new or different (based 
on test and evaluation) CAAT requirements and concepts for NextGen. 

3.1 Alert Definitions 

The SURE IA SPR has adopted the definition of alerts [LAA, 2009] as follows: Alerts refer to flight 
deck annunciations meant to attract the attention of, and identify to the flight crew a non-normal 
operational or airplane system condition. Cautions and warnings are examples of alerts. Caution alerts 
are generated for conditions that require immediate flight crew awareness and subsequent flight crew 
response. An auditory signal and the yellow/amber color are associated with cautions. Warning alerts are 
generated for conditions that require immediate flight crew awareness and immediate flight crew 
response. An auditory signal and the red color are associated with warnings. 

The criteria and thresholds used for the ATCAM alerts are defined in Sections 5.4, 5.5, and 5.6. 
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Figure 1 . ATCAM High Level Flow Diagram 
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The alert terminology used by ATCAM is as follows: 

3.1.1 Caution Alert 

A caution alert provides immediate awareness of other traffic that may cause an unsafe or a hazardous 
situation. In the initial design, cautions are issued by LACM and TCM for low altitude and taxi 
operations and by RSM for runway incursions during approach or when holding in position on the 
runway. The feasibility and appropriateness of generating caution alerts for these types of operations will 
be determined based on test and evaluation. Avoidance maneuvers are not required and resolution 
instructions are not given when a caution is issued. In some cases, appropriate action may be advisable at 
the pilot’s discretion to prevent the condition from progressing to a more serious situation. For example, 
when a caution is issued for taxi operations, avoidance action such as slowing down or stopping may be 
done to prevent the situation from progressing to the point a warning alert is warranted. 

3.1.2 Warning Alert 

A warning alert indicates there is a high probability of collision or near collision with other traffic 
and, therefore, avoidance maneuvering should be initiated. The specific maneuver taken (e.g., go-around, 
abort takeoff, stop taxi, etc.) is at the pilot’s discretion. Warnings are issued by RSM, LACM and TCM 
using criteria and thresholds that are algorithm specific. The criteria and thresholds will be refined based 
on test and evaluation. 

3.1.3 Resolution Advisories (RA) 

RAs are intended to provide the pilot direction on the maneuver to take to safely avoid a collision. 
RAs are issued in the current version of ATCAM, in prototype form. Further research is required, and 
currently in progress, to determine the feasibility of providing RAs in conjunction with warning alerts to 
effectively resolve conflict situations without producing undesired consequences. For example, what 
avoidance maneuvers should be taken without creating secondary conflicts with other traffic? Section 
6.0, Initial Requirements for ATCAM Resolution Advisories, describes current RA research. 

3.2 Indication Definitions 

In addition to alerts, the SURF IA SPR has also adopted the definition of indications [RTCA, 2010b], 
as follows: Indications identify to the flight crew a normal operational condition that could become a 
runway safety hazard. Indications do not actively attract attention from flight crews but provide enhanced 
situation relevant information to facilitate flight crew perception of safety hazards. Indications are not 
alerts. 

Only the RSM algorithm currently implements indications (as defined in the SURF IA SPR [RTCA, 
2010b]), for potential runway conflicts. Neither LACM nor TCM implement indications for low altitude 
or taxi scenarios. 

3.2.1 Traffic Indication (TI) 

Traffic indication (TI) highlights a potential runway traffic collision/hazard that may emerge in the 
near future. TIs are intended to increase the flight crews’ awareness of relevant traffic that could affect 
runway safety. If appropriately cleared, the flight crew proceeds with the intended operation. 

3.2.2 Runway Status Indication (RSI) 

Runway Status Indication (RSI) identifies if the runway that own-ship is approaching or using is in- 
use or occupied by other traffic. Before proceeding, the crew should ensure they have the appropriate 
clearance and the indicated traffic is not a factor. Note: The absence of an RSI does not alleviate pilots 
from verifying the runway status prior to proceeding. 
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3.3 Runway Safety Monitor (RSM) 


RSM monitors data for the ownship aircraft and other aircraft or vehicles and predicts potential 
incursions/collisions and notifies the flight crew to avoid a possible incursion/collision. Testing has 
included single runway, intersecting runways and intersecting flight path scenarios during both simulation 
and flight [Green, 2006, Jones, 2002 and 2005, Jones et al., 2001, and Jones and Prinzel, 2006]. In some 
scenarios, RSM detects a runway incursion early and issues an alert before the situation degenerates into a 
severe incursion. In other scenarios, RSM predicts the incursion before it occurs and alerts the pilot early 
to avoid the incursion. RSM also detects runway conflicts that are not part of the strict definition of 
runway incursion, such as when both aircraft are airborne in the process of landing in the approach phase 
and/or taking off in the climb out phase. RSM is generic for both general aviation (GA) and large 
commercial air carrier operations, and for any ownship aircraft type. The most recent version of RSM is 
described in detail in [Green, 2006]. 

A major concept of RSM is the use of runway incursion (RI) zones. A RI zone is a three-dimensional 
virtual zone that overlays a runway and the approach area. A detailed description of the RI zone 
placement is given in Section 5.4.2. A two-dimensional plan view of the RI zones at the Wallops Flight 
Facility is shown in Figure 2. RSM monitors for conflicts/incursions only when the ownship is inside a 
RI zone and traffic is inside or approaching the same zone as the ownship or in an intersecting zone. 



Figure 2. Runway Incursion Zones at Wallops Flight Facility 


Another major RSM concept is the use of operational states for the ownship and traffic. Seven 
operational states or flight phases are defined: taxi, pre -takeoff, takeoff roll, climb-out, approach, rollout 
and fly-thru. These states are described in Appendix A. Combinations of these states between the 
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ownship and traffic, positions inside the RI zones, and other criteria determine whether or not an 
indication or alert will be issued. More detail is provided in Section 5.4 and Appendices A, B, and C. 

CD&R under the RIPS concept includes aural and visual displays in the flight deck. For instance, an 
airport map display depicting a warning alert for a runway incursion from a simulation at the Chicago 
(ORD) airport is shown in Figure 3. 



Figure 3. Airport Map Display showing Warning Alert for a Runway Incursion 

3.4 Low Altitude Conflict Monitor (LACM) 

The intent of the LACM algorithm is to monitor conflicts that can occur at low altitudes near the 
airport including conflicts that may not be detected by RSM. As shown in Figure 1 above, LACM is run 
in addition to RSM. LACM provides conflict detection coverage at altitudes below 1000 feet. The 
implementation of LACM does not utilize aircraft operational state information and RI zones as does 
RSM. Instead, the algorithm’s initial design is based on many of the same concepts that are used in the 
current operational version of TCAS II [FAA, 2000]. However, there are a number of significant 
differences between LACM and TCAS in the way traffic data is obtained, the methods of computation, 
the criteria and thresholds used for alerting, and the types of alerts that are issued (see Section 5.5). Some 
of the TCAS terminology is also used by LACM such as Closest Point of Approach (CPA), time to CPA 
(called range tau) and time to co-altitude (called vertical tau). The technical approach for LACM is to 
compute closing speed, range tau, vertical tau and other data between ownship and an approaching 
aircraft to determine if specific criteria and thresholds are met for issuing alerts. The alerts and 
methodologies used by LACM are designed to achieve the same high level of performance as TCAS and 
are described in Section 5.5. 

Figure 4 gives examples of LACM caution and warning alerts at the ORD airport. In Figure 4a, the 
ownship has departed a runway. The traffic has departed a parallel runway and is turning on a path to 
cross in front of ownship. LACM detects this potential conflict and initially issues a caution (indicated by 
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yellow icons). As the scenario progresses, the aircraft continue toward a potential collision point and 
LACM issues a warning (indicated by red icons), as shown in Figure 4b. 



Caution, Traffic Right and Above 


4a. LACM Caution Alert 



4b. LACM Warning Alert 


Figure 4. LACM Alerts. 


SURFACE TRAFFIC 

01 ST - AIRCRAFT 


NONE LI ALL 


SURFACE TRAFFIC 

01 ST - AIRCRAFT 


NONE LI ALL 
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3.5 Taxi Conflict Monitor (TCM) 


The TCM algorithm is designed to improve safety on the airport surface by monitoring for conditions 
that cause conflicts and collisions during taxi operations for multiple classes of aircraft as well as surface 
vehicles. The algorithm’s design uses an approach similar to LACM by computing distances between 
aircraft, closing speeds, time to closest point of approach (range tau) and other parameters used for alert 
criteria. The obvious difference from LACM is that all aircraft, vehicles, etc., on the airport surface can 
be very close to each other while moving or not moving. 

The close proximity of aircraft and vehicles to one another on the surface requires very strict accuracy 
tolerances. These tolerances, as well as all alert criteria and thresholds for TCM, are described in Section 
5.6. Some of the parameters used by LACM (e.g., vertical speed, altitude, vertical tau, etc.) are not 
required by TCM. However, based on developmental testing, additional alert criteria are required by 
TCM because of the higher probability of nuisance alerts (see Section 5.2). All alert criteria and 
thresholds are described in Section 5.6. Because TCM is based on the LACM and the TCAS concept, the 
algorithm does not use a detailed database of airport taxiways, runways and ramps. 

The feasibility of utilizing traffic’s ATC clearances, specifically, assigned taxi route and hold short 
instructions, as a factor in taxi conflict detection and alerting is being investigated. Knowledge of the 
traffic’s intent on the surface combined with the current state information could result in delayed alerting 
and reduced nuisance alerts. A detailed database of the airport including taxiways and ramp areas would 
be required in this instance. Future versions of TCM may utilize this information if determined to be a 
feasible approach. 

Figure 5 gives examples of TCM caution and warning alerts. In Figure 5a, the taxiing traffic and 
ownship are approaching the same intersection as ownship exits the runway after landing. TCM detects 
this potential conflict, and initially issues a caution (indicated by yellow icons). In Figure 5b, as the 
aircraft continue to converge, TCM issues a warning (indicated by red icons). 



5a. TCM Caution Alert 
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5b. TCM Warning Alert 


Figure 5. TCM Alerts between commercial aircraft. 

4 ATCAM Data Communications 

The ICAO defined operational requirements for Advanced Surface Movement Guidance and Control 
Systems (A-SMGCS) are to achieve safe, orderly and expeditious movement of aircraft and vehicles at 
airports under all visibility conditions, traffic densities, and airport layouts. These standards were 
proposed by ICAO to ensure safety and standardization with respect to global interoperability [ICAO, 
1997]. NASA and its industry partners developed a prototype A-SMGCS architecture and operational 
concept that was initially designed to improve operational capability. This operational concept and 
system design have been tested in both full-mission simulation and operational flight test experiments at 
major airport facilities. The data structure developed for the first implementation of an aircraft -based A- 
SMGCS, demonstrated at the Atlanta Hartsfield International Airport in 1997 [Jones and Young, 1998], 
coupled with the enhanced design to provide runway incursion detection and alerting demonstrated at 
Dallas-Fort Worth International Airport in 2000 [Jones et al., 2001] were used as the basis for the current 
data parameters for ATCAM. 

ATCAM data communications is handled by a separate software program that accesses data from 
various sources available on the aircraft and provides the data to ATCAM. Flight and traffic data are 
obtained from available sources and converted and processed into the format required by ATCAM. This 
method of data communications has been utilized successfully in past RIPS research and has proven to be 
highly reliable and effective during flight tests and simulations. A significant advantage of this method is 
that ATCAM does not have to perform data communications functions. Appendix D lists the current data 
parameters used by ATCAM. 

Appendix E contains a discussion on surveillance performance and intent data as it relates to ATMA 
CD&R. 
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4.1 Ownship Data 


The ownship data used by the ATCAM software is obtained from the aircraft systems and consists of 
the data described in Appendix D, as available. Additional parameters may be required with future 
development of the ATCAM software. 


4.2 Traffic Data 

Data for airport traffic can be obtained from several different sources, such as: 

• Traffic Information Service-Broadcast (TIS-B) comprised of traffic information from surface 
surveillance radar and multi -later ation [RTCA, 2007], 

• Automatic Dependent Surveillance-Broadcast (ADS-B) [RTCA, 2002], 

• TCAS [FAA, 2000], and 

• GPS-based surface vehicle location tracking system such as Era Corporation’s Squid [Era, 2008]. 

Appendix D contains a list of the traffic data parameters currently used by ATCAM. 

For CAAT, the data communications software accesses traffic data from any available source. If any 
of the parameters are not available from the data source in use, they are marked accordingly, so that 
ATCAM does not attempt to use any spurious values. Unavailable parameters may be computed 
independently, or may be subject to data smoothing, described below. ADS-B Out deployment has been 
mandated and is expected to be the primary source for future NextGen requirements. However, current 
Mode-S/Mode-C TCAS data (range, bearing and relative altitude) will continue to be used as well as 
other new sources from on-board sensors and ground systems. Since ATCAM does not utilize range, 
bearing and relative altitude, TCAS data must be converted to lat/long and altitude mean sea level (MSL) 
by the communications program for use by ATCAM. Currently, ATCAM accesses data once per second, 
regardless of the rate at which the data was received. 

When traffic parameters are not reported or not up to date, an estimate of the current value(s) must be 
computed by the algorithms based on the last known value(s). This process, known as data smoothing, 
involves computations that decrease in accuracy with increasing time between updates. Computation 
accuracy is further decreased if data rates for specific values are different and the exact times since the 
last update are uncertain (for example, the position update is one hertz but the ground speed is updated at 
two or three hertz and the exact update times are unknown). 

4.3 Output Data 

ATCAM output parameters provide information on the generated alert or indication and conflict 
traffic to enable display of the alert or indication to the flight crew or ATC. The specific output 
parameters for the alert or indication are based on the aural and graphical flight deck alerting display 
requirements. The current ATCAM output parameters, listed below, were defined for RSM alerts. 
Additional parameters are available in RSM and can be provided in future upgrades as required. Other 
output parameters derived from LACM and TCM alerting display requirements will also be added as 
required. 

• Traffic ID (e.g., ICAO aircraft address) 

• Alert code 

• Distance to traffic (range) 

• Distance to collision point 

• Time (sec) to collision point 

• Time (sec) to closest point of approach (range tau) 

• Traffic bearing relative to ownship 

• Traffic relative altitude 


13 



• RA maneuver, if provided (RSM or TCM) 

Or 

Horizontal, vertical and acceleration maneuver & navigation pairs (LACM) 

The alert code is a single four digit hex number that compresses information including type of alert or 
indication (i.e., caution or warning, TI or RSI), the name of the traffic’s runway and the traffic’s 
departure/arrival status (for example, a warning for traffic departing runway 25). The efficient encoding 
and decoding routines used to generate the alert code are generic for any aiiport and compatible with the 
ATC two-way Controller-Pilot Data Link Communications (CPDLC) protocols defined in references 
[ICAO, 1999] and [RTCA, 1993]. A benefit of being compatible with CPDLC is the alert information 
can be data linked to ATC for display on a controller’s workstation as well as be presented aurally, 
visually or both to the pilot. 

When an alert is given, an RA directive may be provided to the pilot. For RSM, a runway maneuver 
may be directed, such as go around. For TCM, a taxi maneuver such as slow down may be directed. For 
LACM, however, a horizontal, vertical, acceleration or a combination of these maneuvers and 
corresponding navigation may be directed. Examples of this include climb 300 ft/min (vertical), bear left 
30 degrees (horizontal) or reduce speed (acceleration). A more detailed discussion of RAs is located in 
Section 6, Initial Description of ATCAM Resolution Advisories. 

5 Technical Description of ATCAM Algorithms 

The previous section described data communications and parameters for the ATCAM algorithms. 
This section provides a technical description for each of the three algorithms. The first three subsections 
on integration of algorithms, performance, and aircraft reference positions are applicable to all three 
algorithms. Finally, algorithm-specific details are presented. 

5.1 Integration of Algorithms 

Because there is overlap in the coverage of component algorithms in ATCAM, the algorithms are 
integrated to share data and insure that consistent and accurate alerts are issued. The LACM algorithm is 
integrated with the RSM algorithm to detect any air-to-air conflicts that RSM does not alert for when the 
conflict does not meet incursion criteria. The TCM algorithm is also integrated with RSM because 
ground taxi conflicts can also be runway incursions if the conflict occurs on or near a runway. Integration 
between LACM and TCM is not necessary since there is no overlap between the algorithms’ operational 
domains. 

The integration of LACM and TCM with RSM is implemented by sharing and coordinating alert 
output data. Since LACM and TCM run after RSM (see Figure 1) and have access to RSM data, 
information is known about ownship and traffic operational states and RSM alert status. This information 
is used to coordinate the alert data that is output for aural and graphical display in the cockpit. For 
example, when air-to-air conflicts are also runway incursions, the ownship and traffic runway status 
information from RSM can be issued in addition to the low altitude alert data. Due to design differences, 
there are cases when alert criteria will be met by only one algorithm or one algorithm may detect a 
conflict earlier than the other. This redundancy in conflict monitoring significantly improves overall 
performance. 


5.2 Algorithm Performance 

The algorithms can be evaluated based on the timeliness of indications and alerts and missed, false, 
and nuisance indication and alert rates. The timeliness of an alert is determined by whether a caution is 
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issued with sufficient time to provide adequate traffic situation awareness prior to a potential hazardous 
situation, or whether a warning is issued with sufficient time for the pilot to take action and safely avoid a 
collision. The definition of missed, false, and nuisance alerts are taken from RTCA 2010b. A missed 
alert is a condition where an alert is needed but not provided, including non-equipped vehicles and 
aircraft. For example, a runway incursion or near collision occurs and a warning is not issued, or aircraft 
come close enough to meet the caution minimum separation threshold but the caution is not issued. A 
false alert is an incorrect or spurious alert caused by a failure of the alerting system including the sensor. 
The false alert rate is composed of ownship avionics failures, undetected ownship avionics errors, map 
integrity, and undetected traffic avionics failures. A nuisance alert is generated by a system that is 
functioning as designed but which is inappropriate or unnecessary for the particular condition. The 
nuisance alert rate is composed of position integrity, ownship accuracy, traffic accuracy, and map 
accuracy. A false or nuisance alert could cause an avoidance maneuver that is not necessary and could 
possibly cause secondary conflicts or unnecessary delays. 

The algorithms are being designed to completely eliminate collisions/near collisions in the airport 
area. To accomplish this goal, performance results should be near zero missed and untimely alerts. 
Analyses are required to determine acceptable missed, nuisance, and false alert rates and desired 
probability of detection. Some analyses have been conducted by RTCA SC-186 WG1 subcommittee for 
runway conflicts [RTCA, 2010b]. 

Performance objectives for RSM have been tested in previous flight tests and piloted simulations. 
The most recent RSM flight test at the Wallops Flight Facility resulted in a success rate of no missed or 
late alerts and only one nuisance alert for all incursion scenarios tested [Green, 2006]. Initial simulation 
evaluations of LACM and TCM have been conducted [Jones et al., 2009 and Jones et al., 2010]. 
Enhancements have been made to LACM and TCM based on these evaluations and are reflected in this 
document. 


5.3 Aircraft Reference Positions 

ATCAM uses the latitude and longitude reported for ownship and traffic as the navigation reference 
point for the aircraft (or vehicles). This reference point is the aircraft center of gravity. To determine 
distance between aircraft, ATCAM measures the distance between the exteriors of the aircraft, not the 
distance between reference points. To determine whether an aircraft is in a runway incursion zone, 
ATCAM considers whether any exterior point of the aircraft is in the zone, not just the reference point. 
ATCAM determines the aircraft exterior points by considering the aircraft type (B-757, DC-7, etc.) and 
using the dimensions for that aircraft type (body length, wing span, distance to nose, and distance to tail). 
If the aircraft type is unknown, ATCAM uses a default type of a large aircraft (B-747) to allow a 
conservative estimate. 


5.4 RSM 


5.4.1 Airport Databases 

RSM does not require detailed terrain or airport databases that include taxiways, ramps, buildings, 
etc. However, RSM does require highly accurate information for all runways on the airport to include 
latitude and longitude of thresholds and displaced thresholds, runway length and width, length of run-up 
areas, runway true heading, ILS glide slope angle if applicable, runway touchdown aim points, and 
distance from threshold to land-and-hold-short positions on the runway. The existence of intersecting 
runways and intersecting arrival/departure flight paths is determined from the aiiport diagram. Required 
information is available from publically-available sources. 

5.4.2 Runway Incursion Zone Placement 

Accurate placement of RI zones is critical for correct performance of the algorithm and prevention of 
missed and nuisance alerts. The coordinates for the sides and ends of each zone are computed based on 
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runway information in the airport configuration file and vary for each runway. The sides of the zones 
along the runways are set to be at or just inside the hold short positions if they are known. If runway hold 
short position data are not available, the sides of zones are placed 200 feet from the runway edges. 

The sides of the zones are extended by a look-ahead distance , if an aircraft outside the zone is taxiing 
toward the zone. The look-ahead distance is based on the distance the aircraft requires to stop, given its 
current ground speed and assuming a standard deceleration rate that is not aircraft type specific. If the 
distance between the aircraft and the zone edge is less than the look-ahead distance, the aircraft is 
considered to be inside the zone. This approach allows RSM to issue alerts in time for the aircraft to stop 
before entering the zone. 

The ends of zones will vary based on the intersection of the ILS glide slope path with the RI zone 
altitude. The example below (Figure 6) shows that with a typical zone altitude of 800 feet and a typical 
glide slope angle of 3 degrees, the end of the zone would be calculated to extend approximately 15,265 
feet prior to the touchdown aim-point. (The touchdown aim-point is abeam the ILS glideslope antenna.) 
Assuming the touchdown aim-point is located 1,000 feet from the end of the runway, the zone would 
extend approximately 14,265 feet, or 2.34 nm, prior to the runway threshold. 



◄ ► 

Approx. 14,265 ft 

Figure 6. Example Using 3 -Degree Glide Slope to Determine Incursion Zone Ends 


The width of extended RI zones is greater at the approach ends than at the runway thresholds as 
shown in Figure 2. Greater detail is shown in Figure 7, in plan view, with the extended zone shaded gray. 
The angle at which the extended zone flares, or increases, is determined by the maximum ILS localizer 
deviation, up to a two-dot deviation. For each dot of ILS error, the zone perimeter is 175 feet from the 
centerline at the runway threshold, as modeled by [Parrish et al., 2006]. The angle of flare for the 
extended zone is determined by using a straight line that starts at the estimated location of the ILS 
antenna, 1,000 feet from the opposite runway threshold, intercepts the defined zone perimeter distance at 
the runway threshold, and terminates at the end of the extended zone. The example RI zone in Figure 7 
uses a one-dot ILS deviation, and the zone ends at 14,265 feet past the threshold, as determined by the 3- 
degree ILS slope shown in Figure 6. 

All values for RI zone placement can be modified in configuration files to be optimal for any airport. 
Site-specific adaptation of some values may be necessary due to conditions at individual airports. For 
example, if parallel runways are closely spaced, runway zones may need to be narrower. Airports in 
mountainous regions may require steeper glide slopes. Construction at airports may cause runway 
dimensions to change or may lead to creation of new runways or removal of existing runways. 
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Extended Runway 



Figure 7. Example Extended Runway Zone with 1 Dot ILS Deviation 

5.4.3 Incursion Scenarios and Alert Criteria 

RSM is designed to detect all possible runway incursion scenarios including conflicts on single 
runways, intersecting runways and intersecting flight paths. This capability is accomplished using a 
generic approach that is based on the concept of ownship and traffic operational states as defined in 
Appendix A. Conflict scenarios are defined by the combination of operational states that determine 
whether or not alert criteria should be tested for conflicts. There are separate criteria for single runway 
and intersecting runway/flight path conflicts. Appendix B describes the alert criteria and default 
thresholds and provides a set of tables that define the scenario conditions for all possible combinations of 
ownship and traffic states. Appendix C provides a mapping between RSM operational states and SURF 
IA operational states, and RTCA 2010b describes the criteria, thresholds, and state combination tables for 
SURF IA indications. 

5.4.4 Determining Operational States 

Since incursion scenarios and indication and alert criteria are based on the operational states of 
ownship and traffic (Section 5.4.3 above), the correct performance of RSM depends on, among other 
things, how accurately these states are determined. The criteria and data for determining states include on 
or off the runway, heading/track in direction of runway, ground speed, acceleration, altitude and vertical 
speed. 

Additional data may also be available for determining ownship states such as auto throttle, engine 
pressure ratio (EPR) mode, throttle position, thrust reversers, air-ground, nose wheel squat, etc. (see 
Appendix D and Table Dl). Ownship states can be computed accurately because the additional data help 
to indicate “intent” to takeoff, “intent” to land, etc. Flowever, these intent data are not available for 
traffic. Although RSM has good results in computing traffic states without the intent data, accuracy could 
potentially be improved if this data becomes available. See discussion on intent data in Appendix E. 

5.4.5 Alert Output Data 

The current alert output parameters for the RSM caution and warning, that provide the flight crew 
with optimal alert awareness, are based on the aural and graphical display requirements developed 
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through simulation and flight testing. The current parameters are listed in Section 4.3. Additional 
parameters are available in RSM and can be provided in future upgrades as required. 

5.5 LACM 


5.5.1 Integration with TCAS 

LACM is designed to detect and alert for air-to-air conflicts at low altitudes near the airport without 
conflicting with TCAS operation. As mentioned in Section 2.2, TCAS resolution advisories are inhibited 
below 1000 feet AGL ±100 feet and aural traffic advisories are inhibited below 500 feet AGL. LACM 
monitors for conflicts below 1000 feet AGL. Any overlap in coverage with TCAS will require 
integration and coordination so LACM does not interfere with existing TCAS operations. For example, 
LACM will not alert if TCAS is already alerting for the same traffic. Research regarding LACM and 
TCAS integration is necessary. The results of this research could possibly support RTCA SC- 147 
objectives (see Section 2.2). 

5.5.2 Traffic Data and Computations 

A major difference between LACM and TCAS design is the way traffic data is acquired and the 
resulting methods of computing distance to aircraft, bearing, and closing speed. TCAS uses Mode S and 
Mode C surveillance of nearby airborne traffic at exact time intervals to continually measure the distance 
(range), direction (bearing), and altitude (if available). This system provides accurate, timely, and 
consistent data to compute parameters. TCAS determines closing speed between ownship and traffic by 
interrogating nearby Mode C or Mode S transponder -equipped traffic and using the position data to 
compute changes in distance over time. 

Currently, LACM does not use TCAS Mode-S/Mode-C data directly but primarily depends on data 
available from ADS-B. (See Section 4) Closing speed is critical in determining the timing of a potential 
conflict. During previous RSM research, closing speed had been calculated using ADS-B aircraft 
position data, and the timestamps associated with that data. However, flight testing found that using 
ADS-B position reports and associated timestamps to calculate closing speeds produced erratic results 
since neither of these data items were reported with sufficient accuracy. Future upgrades to ADS-B may 
improve accuracy and timeliness; however, an immediate solution is needed. 

Another method of computing closing speed is to use ADS-B ground speeds that are consistent and 
not as dependent on time stamps as position data. By computing the components of ground speed in the 
direction of closure for both ownship and traffic, and comparing these components, the closing speeds 
and times to CPA are highly accurate and smooth (not erratic). This method of computation is currently 
used by LACM when ADS-B is the data source. Further testing is needed to determine how sensitive this 
method is to variations in flight data accuracy. 

5.5.3 Monitoring and Alert Criteria 

Since LACM is designed to operate at low altitudes, the monitoring and alert criteria and thresholds 
must be optimized to prevent nuisance alerts and allow sufficient lead time for avoidance action to 
prevent collisions. The current alert criteria are based on those used by TCAS but thresholds may differ 
based on testing and operational requirements (e.g., approach spacing, etc.). For example, criteria for 
time to CPA (range tau) and time to co-altitude (vertical tau), may have different thresholds for LACM, to 
customize the lead time for pilot response to alerts. Also, to prevent nuisance alerts, some additional 
LACM criteria are required such as projected separation at CPA, relative altitude at CPA, and position of 
CPA on the ground or airborne. Table 1 lists the initial traffic monitoring and alert criteria, and 
thresholds that have been determined based on developmental testing and evaluation. The threshold 
values for monitoring and alerts are contained in software configuration files and can be modified as 
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required based on future testing. For a caution or warning to be issued, all criteria listed in the table must 
be satisfied. 

For LACM criteria which specify a distance threshold, the distance is measured from the aircraft 
center of gravity (CG). Distance between ownship and traffic is measured from the ownship CG to the 
traffic CG. 

Table 1 . Initial LACM Alert Criteria and Thresholds 


Monitoring Criteria 

Target proximity < 18000 ft from ownship position. 
Ownship and target altitudes 50 - 1000 ft AGL ±100 ft. 

Alert Criteria 

Caution 

Warning 

Range tau (sec) 

<35 

<20 

OR current distance to target (range) (ft) 

<2000 

<1200 

Vertical tau (sec) 

<35 

<20 

OR current relative altitude (ft) 

<1000 

<400 

OR projected relative altitude at CPA (ft) 

<1000 

<400 

Projected horizontal separation at CPA (ft) 

<2000 

<1200 

Projected ownship and/or target altitudes at CPA (ft) 
(Own/target not near the ground at CPA) 

>50 

>50 


5.5.4 Alert Data Output 

The parameters that are output for the LACM caution and warning depend on the cockpit alerting 
display (aural and graphical) requirements for NextGen. The future alert display requirements are 
unknown at this time, but a list of parameters can be constructed based on previous RIPS alert output as 
well as display data currently utilized by TCAS. The following list of alert output parameters is based on 
developmental testing and evaluation but is subject to change based on future testing and requirements. 
Alert parameters previously used for RIPS are identified with asterisks. 

• Traffic ID (e.g., ICAO aircraft address)* 

• Alert code (includes type of alert caution/warning, traffic runway, traffic arrival/departure state)* 

• Distance to traffic (range)* 

• Time (sec) to collision or closest point of approach (range tau)* 

• Bearing 

• Traffic air or ground 

• Relative altitude (if airborne) 

• Traffic climb/descend (if airborne) 

• Time (sec) to co-altitude (vertical tau) (if airborne) 

5.6 TCM 

In taxi scenarios, the traffic may be an aircraft or a surface vehicle. In this discussion, the term 
"vehicle" refers to both aircraft and surface vehicles. 

5.6.1 Data Accuracy 

A high degree of data accuracy is necessary because of the very close distance and time tolerances 
involved in surface conflict situations and the greater likelihood of nuisance alerting. The criteria and 
threshold tables in the next section indicate the accommodations TCM makes for variations in data 
accuracy. 
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Ground speed accuracy can be problematic since reported ground speed can be incorrect by more than 
one knot, and a stationary vehicle may report a non-zero ground speed. Therefore, TCM allows for a 
discrepancy of up to two knots for reported ground speed. 

Specific data accuracy requirements are yet to be determined. 

5.6.2 Monitoring and Alert Criteria 

Since TCM is designed to operate only when the ownship is on the ground, the monitoring and alert 
criteria and associated thresholds must be optimized for much closer tolerances than for airborne 
operations. The thresholds must be set to allow sufficient lead times to prevent collisions but minimize or 
eliminate over-alerting. 

For TCM criteria which specify a distance threshold, the distance is measured differently from RSM 
and LACM, due to the closer proximity between vehicles and the need for greater precision. Distance for 
TCM is measured from the vehicle exterior instead of from the aircraft CG. For example, if ownship is 
following traffic, the distance between vehicles is measured from the ownship nose to the traffic tail. 

Table 2 lists the monitoring criteria, alert criteria and thresholds that have been determined based on 
developmental and simulation testing [Jones et al., 2009 and Jones et al., 2010]. These criteria are applied 
in a three-step process. 

5.6.2. 1 Step 1 - General Criteria 

In Step 1, monitoring criteria determine what traffic is monitored for conflicts, and alert criteria 
determine if and which alerts to issue. The threshold values for monitoring and alerts are contained in 
software configuration files and can be modified as required based on future testing. For a caution or 
warning to be issued, all criteria for Step 1 (see Table 2) must be satisfied. The threshold modification 
factors listed in Table 3 are secondary criteria that modify the standard thresholds to prevent nuisance 
alerting and alert toggling (alerts on and off or switching between caution and warning). 

In Table 2, special treatment is given to the minimum separation threshold for cautions. The standard 
value for this threshold is 50 feet, but a larger value may be used, depending on vehicle size. If either the 
ownship radius or the traffic radius is greater than 50 feet, the radius of the larger vehicle is used for 
minimum separation. For example, if ownship is a B757 with a body radius of 77.4 feet, and the target is 
a DC3 with a body radius of 32.5 feet, then 77.4 feet would be the threshold value. Vehicle size is not 
used to determine the minimum separation threshold for warnings, which has a standard value of 30 feet. 

5.6.2.2 Step 2 - Following Criteria 

If Step 1 does not issue an alert, then Step 2 is applied. Step 2 has a single criterion, which is only 
applied if one vehicle is following the other. 

The goal of this step is to calculate a safe separation distance for the following vehicle, so that an alert 
may be issued if separation is not adequate. This distance threshold is calculated using the following 
vehicle's ground speed and body length. 

The criterion in Table 2, “Ground speed per body length of separation”, specifies the ground speed at 
which the distance threshold is equal to one body length of separation. This criterion is abbreviated 
bodyLengthKnots . The default values are 8 knots for a caution, and 1 1 knots for a warning. 

If ground speed is greater than bodyLengthKnots, then the required separation is proportionally 
larger than one body length. If ground speed is less than bodyLengthKnots, then the required 
separation is proportionally less than one body length. The formula is below: 

(groundSpeed / bodyLengthKnots) * bodyLength = separationThreshold 
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Table 2. Initial TCM Alert Criteria and Thresholds 


Monitoring Criteria 

Target proximity < 1500 ft fro 
Either ownship or target speec 

im ownship position. 

1 must be > 5 kts. (No alert if both stopped or both < 5 kts) 

Alert Criteria - Step 1 

Standard Thrcsho 

ds* 

Threshold 

Modification Factors 

Modi 

Thresl 

fied 

rolds 

Caution 

WA 

+ 

CA+ 

WA 

+ 

Range tau (sec) 

18 

10 

one stopped 

12 

7 

slower taxi 

16 

7 

same Direction 

12 

7 

Turning 

12 

7 

Following 

10 

7 

head-on 

18 

10 

turning head-on 

no 

limit 

10 

Current distance to target 
(range) 

< min alert distance (ft) 

700 

400 

one stopped AND 
slower taxi 

150 

150 

turning AND 
in path 

150 

150 

head-on 

900 

600 

Projected separation at CPA 

< min separation (ft) 

OR 

Current distance to target 
(range) 

< min separation (ft) 

Maximum: 

50, or 

ownship radius, or 
target radius 

30 

one stopped 
AND slower taxi 

15 

15 

not one stopped 
AND slower taxi 
AND same Direction 
AND in path 

10 

10 

slower taxi 
AND range tau = 0 

20 

20 

one stopped 
OR slower taxi 

40 

30 

WA in progress 

60 

45 

CA in progress 

60 

30 

Alert Criteria - Step 2 

Threshold 

Modification Factors 

CA 

WA 

Ground speed per body length of separation (kts) 
(use body length of vehicle that is following) 

Following 

8 

11 

Alert Criteria - Step 3 

CA 

WA 

Current distance to target (range) = very close (ft) 

<10 

0 


* Standard thresholds are used when no threshold modification factors apply. 
+ CA = caution WA = warning 
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Table 3. Initial TCM Threshold Modification Factors 


Threshold Modification 
Factors 

Description 

One stopped 

At least one vehicle is stopped or moving < 2 kts. 

Slower taxi 

Both vehicles are taxiing < 15.5 kts. (One can be stopped.) 

Same direction 

Both vehicles are moving in the same direction within ±50° of 
heading. 

Turning 

One or both vehicles is/are turning with turn rate > 4°/sec. 

Following 

One vehicle is following the other and neither is stopped. 

In path 

One of the vehicles is in the path of the other, and neither is stopped 

Head-on 

Both vehicles are in each other’s paths within ±15°. 

Turning head-on 

Ownship is turning with turn rate > 4°/sec, and turn is projected to 
cause head-on conflict, with paths within ±15°. Condition has lasted 
for at least 5 seconds. Traffic may be stopped or moving. 


For example, if ownship is a B757, body length 154.8 feet, taxiing behind a DC3 at 15 knots, then the 
separation threshold to trigger a caution is: 

(15 / 8) * 154.8 = 290.25 feet 

The separation threshold to trigger a warning is: 

(15 / 11) * 154.8 = 211.09 feet 

So a caution is triggered if ownship follows within 290.25 feet of the traffic, and a warning is triggered if 
ownship follows within 21 1.09 feet. 

If ownship was in front and the traffic was following, the DC3 body length of 65.0 feet would be 
used, instead of 154.8 feet, and traffic ground speed would be used instead of 15 knots. 

5. 6.2.3 Step 3 - Close Traffic Criteria 

If neither Step 1 nor Step 2 issues an alert, then Step 3 is applied. If the two vehicles are within 10 
feet of each other, but do not otherwise prompt alerts, a caution is issued. 

5.6.3 Alert Data Output 

The parameters that are output for the TCM caution and warning depend on the cockpit alerting 
display (aural and graphical) requirements for NextGen. The future alert display requirements are 
unknown at this time, but a list of parameters can be constructed based on previous RIPS alert output. 
The following is a list of initial parameters that is subject to change based on future testing and 
requirements. Alert parameters previously used for RIPS are identified with asterisks. 

• Traffic ID (e.g., ICAO aircraft address)* 

• Alert code (type alert caution/warning, traff ic runway and traffic arrival/departure state if 
applicable)* 

• Distance to traffic (range)* 

• Time (sec) to collision or closest point of approach (range tau)* 

• Bearing 
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6 Initial Description of ATCAM Resolution Advisories 

The need or efficacy of Resolution Advisories (RA) for an aircraft-based CD&R system for ATMA 
operations has not been firmly established by research. To conduct this research, RA implementations 
have been created as outlined in this section. Various means are being used to validate this concept, such 
as qualitative pilot evaluation, automated simulation, and piloted simulation. Limited testing of the 
efficacy of recommending avoidance maneuvers has been performed but conclusive results have not been 
achieved. 


6.1 Resolution Advisories 

When ATCAM determines that a conflict has occurred, either a warning, indicating that ownship 
must take avoidance action, or a less severe caution, or both, are issued. When ATCAM issues a 
warning, an RA may also be issued, indicating the maneuver that should be performed by ownship to 
deconflict a possible collision or incursion. Currently, ATCAM determines the resolution maneuver 
based on the conflict scenario. Navigational data, such as turning angle or climb rate, may accompany the 
RA, depending on the scenario. 

If ATCAM issues multiple warnings, an RA is only issued based on the first alert. ATCAM currently 
does not consider the second conflict when determining the RA. Similarly, ATCAM currently does not 
perform any coordinated resolutions with the traffic like TCAS (i.e., it does not project whether the 
resolution maneuver will create a new conflict with other traffic or if the resolution maneuvers being 
performed by each vehicle might in fact conflict). 


6.2 RSMRAs 

This section outlines the approach taken for runway conflict RAs, in RSM. 

6.2. 1 RSM Avoidance Maneuvers 

Table 4 lists the avoidance maneuvers that ATCAM currently defines for runway conflicts. RSM 
RAs only indicate a recommended maneuver, and do not provide navigational guidance. 


Table 4. RSM Avoidance Maneuvers 


Avoidance Maneuver 

Description 

No Resolution Available 

No viable resolution found, leave 
resolution to pilot discretion 

Go Around 

Terminate approach and climb away 

Touchdown Emergency 
Stop 

Expedite landing, decelerate quickly 

Reject Takeoff 

Abort takeoff, stop 

Emergency Stop 

Stop immediately (severe slowdown 
may suffice) 

Exit/Clear Runway 

Proceed immediately to nearest 
runway exit 


6.2.2 RSM Maneuver Selection 

When RSM issues a warning, avoidance maneuvers are considered as shown in Table 5, for each 
ownship/traffic combination. These maneuvers are usually considered in the order shown. 

RSM considers a maneuver by projecting whether or not it will prevent the possible collision. If so, 
that maneuver is used for the RA, and no other maneuvers will be considered. If not, other maneuvers in 
the list will be considered. If none of the candidate maneuvers is projected to prevent the collision, RSM 
issues a ‘No Resolution Available’ maneuver. 


23 




Table 5. RSM Scenario Resolutions 


Ownship 

State 

Traffic 
State * 

Single Runway 
Avoidance Maneuvers 

Intersecting Runway 
Avoidance Maneuvers 

taxi 

taxi 

NA 

NA 

takeoff roll 

Emergency Stop 
Exit/Clear Runway 

NA 

climb-out 

Emergency Stop 
Exit/Clear Runway 

NA 

approach 

Emergency Stop 
Exit/Clear Runway 

NA 

rollout 

Emergency Stop 
Exit/Clear Runway 

NA 

fly-thru 

NA 

NA 

pre-takeoff 

taxi 

Reject Takeoff 
Exit/Clear Runway 

NA 

takeoff roll 

Reject Takeoff 
Exit/Clear Runway 

Reject Takeoff 

climb-out 

Reject Takeoff 
Exit/Clear Runway 

Reject Takeoff 

approach 

Reject Takeoff 
Exit/Clear Runway 

Reject Takeoff 

rollout 

Reject Takeoff 
Exit/Clear Runway 

Reject Takeoff 

fly-thru 

Reject Takeoff 

NA 

takeoff roll 

taxi 

Reject Takeoff 
Exit/Clear Runway 

NA 

takeoff roll 

Reject Takeoff 
Exit/Clear Runway 

Reject Takeoff 

climb-out 

Reject Takeoff 
Exit/Clear Runway 

Reject Takeoff 

approach 

Reject Takeoff 
Exit/Clear Runway 

Reject Takeoff 

rollout 

Reject Takeoff 
Exit/Clear Runway 

Reject Takeoff 

fly-thru 

Reject Takeoff 

NA 

approach 

taxi 

Go Around 

Touchdown Emergency Stop 

NA 

takeoff roll 

Go Around 

Touchdown Emergency Stop 

Touchdown Emergency Stop 

climb-out 

Go Around 

Touchdown Emergency Stop 

Touchdown Emergency Stop 

approach 

Go Around 

Go Around 

Touchdown Emergency Stop 

rollout 

Go Around 

Touchdown Emergency Stop 

Go Around 

Touchdown Emergency Stop 

fly-thru 

Touchdown Emergency Stop 
Go Around 

NA 

rollout 

taxi 

Emergency Stop 
Exit/Clear Runway 

NA 

takeoff roll 

Emergency Stop 
Exit/Clear Runway 

Emergency Stop 

climb-out 

Emergency Stop 
Exit/Clear Runway 

Emergency Stop 

approach 

Emergency Stop 
Exit/Clear Runway 

Emergency Stop 

rollout 

Emergency Stop 
Exit/Clear Runway 

Emergency Stop 

fly-thru 

Emergency Stop 

NA 


* Pre-takeoff state is not currently defined for traffic. ‘NA’ indicates no alert will be issued, so no resolution is necessary. 
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Different methods are used to forecast the results of the various maneuvers. ‘Go Around’ is forecast 
by simulating a climb at 480 ft per minute by ownship, and projecting ownship and traffic positions into 
the future, one second at a time, until time to conflict is 0 seconds. At any one-second interval projection, 
if the conflict is found to no longer exist, then ‘Go Around’ is considered to be a successful maneuver. 
On the other hand, if the conflict exists until ownship passes the projected point of conflict, then the ‘Go 
Around’ maneuver is considered to fail. 

The maneuvers ‘Emergency Stop’, ‘Touchdown Emergency Stop’, and ‘Reject Takeoff are forecast 
by first calculating whether ownship can stop in time to prevent a collision, and then calculating whether 
a conflict will exist once ownship has stopped. If ownship can stop in time and no conflict will exist 
afterward, the maneuver is considered to be successful; otherwise, it is considered to fail. Stopping 
distance for ‘Touchdown Emergency Stop’ and ‘Reject Takeoff is calculated using a deceleration rate of 
-8 kts per second per second. For ‘Emergency Stop’, a deceleration rate of -5 kts per second per second is 
used. 

The maneuver ‘Exit/Clear Runway’ is actually not forecast at all, but is issued as a default second 
choice in some scenarios. If the maneuver of first choice fails, then ‘Exit/Clear Runway’ will be used. 
This maneuver is discussed more below, under “Runway Exits”. 

6.2.3 RSM Unresolved Scenarios 

As shown in Table 6, all scenarios in which ownship is in climb out or fly through states are assigned 
‘No Resolution Available’. 


Table 6. RSM Unresolved Scenarios 


Ownship 

State 

Traffic 

State 

Single Runway 
Avoidance Maneuvers 

Intersecting Runway 
Avoidance Maneuvers 

climb -out 

taxi 

No Resolution Available 

NA 

takeoff roll 

No Resolution Available 

No Resolution Available 

climb -out 

No Resolution Available 

No Resolution Available 

approach 

No Resolution Available 

No Resolution Available 

rollout 

No Resolution Available 

No Resolution Available 

fly-thru 

No Resolution Available 

NA 

fly-thru 

taxi 

NA 

NA 

takeoff roll 

No Resolution Available 

NA 

climb -out 

No Resolution Available 

NA 

approach 

No Resolution Available 

NA 

rollout 

No Resolution Available 

NA 

fly-thru 

NA 

NA 


6.2.4 Runway Exits 

RSM currently does not maintain data on runway exit locations, so the ‘Exit/Clear Runway’ 
maneuver requires clarification. There is no way of discerning whether ownship can reach the nearest 
exit in time to escape a conflict situation. However, if ownship is on the runway and the other viable 
maneuvers, such as ‘Emergency Stop’ or ‘Reject Takeoff do not avoid the conflict, ownship must get out 
of the way somehow, if a true conflict (i.e., not a false alarm or nuisance alert) is confirmed. 

The current interpretation of ‘Exit/Clear Runway’, then, is that the pilot must determine the most 
appropriate location to exit or clear the runway. If reaching a runway exit is not feasible, then the pilot 
should look for another way to get off of the runway, or to move to the side of the runway as far as 
practical. RSM performs no calculation to predict the success of ‘Exit/Clear Runway’. 

A similar issue exists for TCM, when exiting seems a viable maneuver for a taxiing ownship. TCM’s 
approach to this issue is described later, in Section 6.4.4, Taxiway Exits. 
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6.3 LA CM RAs 


This section outlines the approach taken for low altitude conflict RAs, in LACM. 

6.3.1 LACM Avoidance Maneuvers 

As shown in Table 7, LACM avoidance maneuvers are composed of three separate dimensions: 
vertical, horizontal, and acceleration maneuvers. Navigational guidance can be provided for each 
dimension. 

In theory, it is possible for an LACM RA to combine maneuvers from multiple dimensions. For 
example, a single maneuver may involve a vertical climb and a right turn, while accelerating. In practice, 
though, all of the currently-supported maneuvers only involve a single dimension. 


Table 7. LACM Avoidance Maneuver Combinations 


Avoidance 

Maneuver 

Navigational 

Data 

Description 

V.H.A 

v:h:a 

Perform a combination of: 

• Vertical maneuver V, with navigational data v, 

• Horizontal maneuver H , with navigational data h, and 

• Acceleration maneuver A, with navigational data a. 

No Resolution 
Available 


No viable resolution found, leave resolution to pilot 
discretion 


6.3. 1.1 LACM Vertical Maneuvers 

Table 8 lists the vertical avoidance maneuvers that ATCAM defines for low altitude conflicts. 
LACM RAs indicate a recommended vertical maneuver, coupled with navigational guidance which is the 
required vertical rate in feet per minute. 


Table 8. LACM Vertical Avoidance Maneuvers 


Avoidance 
Maneuver (V) 

Navigational 
Data (v fpm) 

Description 

Min 

Max 

Step 

No Change 




Maintain current vertical 
trajectory 

Climb 

500 

4400 

100 

Climb at a rate of v feet per 
minute. 

Reduce Climb 

1 

1 

0 

Reduce rate of climb to v feet 
per minute. (Currently used 
only to implement ‘Level Off.) 


If the vertical maneuver is ‘No Change’, the avoidance maneuver does not have a vertical dimension. 

Navigational Data is listed as a range, because LACM attempts to find the least disruptive maneuver 
which will avert the conflict. LACM first attempts a maneuver using the minimum navigational value 
listed under ‘Min’. If that maneuver does not avert the conflict, LACM adds the value under ‘Step’ to the 
navigational value, and tries again, and keeps incrementing the navigational value by ‘Step’ until it is 
determined that the conflict is averted. The successful value is then included in the RA. If the 
navigational value reaches the maximum value ‘Max’ without averting the conflict, then the maneuver 
fails. 
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The ‘Climb’ maneuver is implemented by first trying a climb at 500 feet per minute. If this climb 
does not avert the conflict, then LACM tries a climb at 600 feet per minute, then 700 feet per minute, and 
so on, until a navigational value is found, or until 4,400 feet per minute is tried. LACM chooses this 
maximum climb rate of 4,400 feet per minute because TCAS also uses that maximum value. However, 
smaller aircraft are not able to climb at such a high rate. ATCAM may be adapted in future version to 
make such navigational data configurable, according to aircraft type. 

‘Reduce Climb’ is currently used only to implement a maneuver identical to ‘Level Off. It was 
meant specifically to address a takeoff scenario in which traffic was too high to climb over, and turning 
was not effective. The maneuver directs the pilot to fly under the traffic. Further testing is needed to 
determine the viability of this maneuver. 

A climb rate of 1 foot per minute is used for ‘Reduce Climb’, instead of 0 feet per minute. This value 
is used because the LACM code internally assumes that a climb rate of 0 indicates that no vertical 
maneuver is intended, and 1 foot per minute is nearly level. 

6.3. 1.2 LACM Horizontal Maneuvers 

Table 9 lists the horizontal avoidance maneuvers that ATCAM defines for low altitude conflicts. 
LACM RAs indicate a recommended horizontal maneuver, coupled with navigational guidance which is 
the angle in degrees by which to turn. 


Table 9. LACM Horizontal Avoidance Maneuvers 


Avoidance 

Maneuver 

(W 

Navigational Data 
(h degrees) 

Description 

Min 

Max 

Step 

No Change 




Maintain current horizontal trajectory. 

Bear Right 

10 

60 

10 

Bear to the right by h degrees. 

Bear Left 

-10 

60 

-10 

Bear to the left by h degrees. 


If the horizontal maneuver is ‘No Change’, the avoidance maneuver does not have a horizontal 
dimension. 

Navigational Data is listed as a range, and LACM steps through horizontal navigational values in the 
same way it steps through vertical navigational values. 

For example, the ‘Bear Right’ maneuver is implemented by first trying a right turn of 10 degrees. If 
this turn does not avert the conflict, then LACM Lies a right turn of 20 degrees, then 30 degrees, and so 
on, until a navigational value is found, or until 60 degrees is Lied. ‘Bear Left’ is implemented in the same 
fashion. 

6.3. 1.3 LACM Acceleration Maneuvers 

Acceleration avoidance maneuvers are currently not implemented (Table 10). More analysis is 
needed to determine how maneuvers such as reduce and increase speed can realistically be recommended. 
Acceleration maneuvers would seem to be more dependent on the capabilities of the individual aircraft 
than vertical or horizontal maneuvers. 


Table 10. LACM Acceleration Avoidance Maneuvers 


Avoidance 
Maneuver (A) 

Navigational 
Data ( a ) 

Description 

No Acceleration 
Maneuver 


Maintain current velocity. 
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6.3.2 LACM Maneuver Selection 

When LACM issues a warning, avoidance maneuvers are considered in the order below. If the first 
maneuver fails, the second is fried, and so on, until the end of the list. 

• ‘Vertical Climb’, determining the climb rate as described above. 

• ‘Level Off /‘Reduce Climb’ maneuver.* 

• ‘Bear Right’, determining the turn angle as described above. 

• ‘Bear Left’, determining the turn angle as described above. 

• ‘No Resolution Available’. 

* If ‘Level Off is successful, LACM actually issues a ‘Reduce Climb’ RA, with a climb rate of 1 fpm. 

LACM considers a maneuver by forecasting whether or not it will prevent the possible collision. 
Each maneuver is forecast by simulating vertical or horizontal movement by ownship, and projecting 
ownship and traffic positions into the future, one second at a time. If, at any one-second interval, the 
conflict is found to no longer exist, then the maneuver is considered to be successful. On the other hand, 
if the conflict exists until ownship passes the point of conflict, then the maneuver is considered to fail. 

6.4 TCMRAs 

This section outlines the approach taken for taxi conflict RAs, in TCM. 

6.4.1 TCM Avoidance Maneuvers 

Table 1 1 lists the avoidance maneuvers that ATCAM defines for taxi conflicts. TCM RAs only 
indicate a recommended maneuver, and do not provide navigational guidance. 


Table 1 1 . TCM Avoidance Maneuvers 


Avoidance 

Maneuver 

Description 

No Resolution 
Available 

No viable resolution found, leave resolution to pilot 
discretion 

Emergency Stop 

Stop immediately (severe slowdown may suffice) 

Slow Down 

Reduce taxi speed 

Speed Up 

Increase taxi speed 


6.4.2 TCM Maneuver Selection 

When TCM issues a warning, avoidance maneuvers are considered in the order below. If the first 
maneuver fails, the second is fried, and so on, until the end of the list. 


• ‘Slow Down’ 

• ‘Emergency Stop’ 

• ‘Speed Up’ 

• ‘No Resolution Available’. 


TCM considers a maneuver by forecasting whether or not it will prevent the possible collision. Each 
maneuver is forecast by simulating acceleration or deceleration by ownship, and projecting ownship and 
traffic positions into the future, one second at a time. If, at any one-second interval, the conflict is found 
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to no longer exist, then the maneuver is considered to be successful. On the other hand, if the conflict 
exists until ownship passes the point of conflict, then the maneuver is considered to fail. 

6.4.3 TCM Unresolved Scenarios 

TCM currently assigns ‘No Resolution Available’ for head-on conflicts, in which ownship and traff ic 
are moving in opposite directions toward each other. None of the currently-supported maneuvers allow 
ownship to move out of the way of traffic in this scenario. 

6.4.4 Taxiway Exits 

TCM currently does not maintain data on taxiway locations. If ownship is on a taxiway, TCM has 
no way of discerning whether ownship can reach the nearest taxiway intersection in time to escape a 
conflict situation. In a large gate area or a wide taxiway intersection, ownship has more flexibility, but 
TCM cannot exploit this flexibility without taxiway or gate knowledge. 

A similar issue exists for RSM, when exiting the runway is the only viable maneuver. RSM does not 
maintain runway exit data, but still uses the ‘Exit/Clear Runway’. An ‘Exit Taxiway’ maneuver could be 
considered for TCM. Currently, though, ‘No Resolution Available’ is used in such scenarios. Taxi 
speeds are slower, so split-second reaction is less critical, and 'Exit' sometimes makes less sense while 
taxiing, for example in gate areas. 

If, in the future, taxiway data and taxi routing information are added to ATCAM, then a 'Turn Right' 
and 'Turn Left' maneuver could be added which specifies which taxiway to turn onto. With such 
additional data, ATCAM would be able to confidently project whether ownship can reach the next 
intersection in time, whether the intersecting taxiway is already occupied by other traffic, or whether any 
traffic is approaching that taxiway. 


6.5 Pilot Reaction Delays 

To realistically forecast the potential success of a candidate avoidance maneuver, ATCAM includes 
an estimated pilot reaction delay. A pilot does not respond to an alert instantaneously. Some time is 
taken to notice and understand the alert and decide on a response, before undertaking avoidance action. If 
ATCAM were to assume immediate action, the pilot may not be able to perform the recommended 
maneuver in time to avoid the conflict as predicted. 

ATCAM estimates pilot delay periods as listed in Table 12. The values were obtained from 
averaging pilot reaction data from previous flight and simulation studies. Pilot delays are not listed for 
RSM operational states climb-out and fly-thru, since RAs are currently not issued when ownship is in 
those states. 


Table 12. Estimated Pilot Delays 


Algorithm 

Operational 

State 

Pilot Delay 
(seconds) 

RSM 

approach 

5 

RSM 

rollout 

3 

RSM 

taxi 

2 

RSM 

pre-takeoff 

2 

RSM 

takeoff roll 

2 

LACM 


3 

TCM 


2 


If an alert is not already in progress when a warning alert is issued, ATCAM calculates that ownship 
will continue on its current trajectory during the pilot delay period, before ownship performs the 
maneuver. For example, if ownship is on approach, ATCAM calculates whether a Go Around will work 


29 




by projecting that ownship will continue its approach for five seconds, and will then begin the Go Around 
climb. 

If an RA is already in progress from a previous warning alert and a new warning alert is issued, 
ATCAM attempts to use the avoidance maneuver from the alert already in progress to resolve the latest 
conflict. In this case, ATCAM does not consider the pilot delay to decide whether the maneuver can still 
avoid the conflict, since the pilot delay has already been accounted for in the initial calculation. 

7 Summary 

NASA is conducting research to enable safe airport operations for both current and future NextGen 
operations. Aircraft-based conflict detection and alerting algorithms (known as the Airport Traffic 
Collision Avoidance Monitor (ATCAM)) are being developed to detect potential traffic conflicts in the 
terminal area and generate indications and alerts that can be displayed to the pilot. 

ATCAM is comprised of three separate but integrated algorithms that operate at low altitudes near the 
airport, on the runway, and during taxi and ramp operations for multiple classes of aircraft as well as 
surface vehicles. The Runway Safety Monitor (RSM) detects runway incursion conflicts and generates 
indications and alerts that provide the flight crew with sufficient awareness to take action to avoid a 
collision. RSM has been under development and testing for many years and has proven to be effective in 
reducing all types of runway incursions and eliminating the most severe incursions. The Low Altitude 
Conflict Monitor (LACM) detects and alerts for air-to-air conflicts at low altitudes near the airport 
without conflicting with TCAS. The Taxi Conflict Monitor (TCM) detects and alerts for ground taxi 
conflicts anywhere in the airport movement and ramp areas. LACM and TCM are in development; 
however, initial testing has proved to be very promising for elimination of collisions in these operating 
areas. The technical approaches for each of these algorithms are presented in this report along with the 
data communications that are necessary for successful implementation and integration. 

Work is currently in progress to test and refine the algorithms as part of NextGen research. This work 
is also being closely coordinated with other NASA research in emerging NextGen technologies including 
synthetic and enhanced vision systems and 4D surface operations. On-going surface safety research also 
includes determination of the feasibility and development of requirements for conflict resolution 
advisories. 
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Appendix A - RSM Operational States 


The ownship (O) and traffic (T) operational states used by RSM are defined as follows: 


taxi state: 
pre -takeoff state: 

takeoff roll state: 
climb-out state: 
approach state: 
rollout state: 
fly-thru state: 


Aircraft/vehicles taxiing or stopped and stationary obstacles or equipment. 
Ownship positioned for takeoff but before or at the beginning of takeoff roll. 
(This state is not available for traffic.) 

Ground takeoff roll in progress, not airborne. 

Airborne climb out after takeoff roll or after an aborted landing. 

Airborne on final approach. 

Ground roll out after landing or after an aborted takeoff. 

Flying through or crossing the RI zone but not landing or taking off. Includes 
turning from the runway heading during departure climb out or go-around 


The operational states are determined using the criteria described in the tables below. Table A1 
describes the criteria used to determine ownship operational states, supplemented by the ownship takeoff 
mode criteria described in Table A2. Table A3 describes the criteria used to determine traffic operational 
states. Table A4 details how the criteria from Tables A1 and A3 are used to define each operational state. 

The threshold parameters listed in these tables are customizable via configuration files. The ownship 
parameters can be configured differently for each type of ownship aircraft, while the traffic parameters 
are applied generically to all traffic aircraft. The threshold values listed under “Default Thresholds” 
should be considered examples, and can be adjusted as necessary. The general aviation thresholds under 
“GA” are untested estimates, and are expected to be refined based on future simulation and flight testing. 


Table A1 . Ownship Operational State Criteria & Default Thresholds 


Operational State Criteria - Ownship 

Code 

Description * 

Default Threshold 

GA** 

Non-GA 

A 

Altitude above ground level (ft) <= 0 

NA 

NA 

B 

All wheels on the ground (true/false) 

NA 

NA 

C 

Ground speed <= taxi high speed (knots) 

20 

40 

D 

Aircraft is on the runway 

NA 

NA 

E 

True heading differs from runway zone true heading <= heading 
tolerance (degrees) 

10 

10 

F 

In takeoff mode (true/false), from Table A2: 

FI or (F2 and F7) or ((F3 or F4) and F5) or (C and F8) or ((not C) and F6) 

NA 

NA 

G 

Vertical speed > minimum climb-out vertical speed (ft/min) 

60 

60 

H 

Distance from ownship position to end of runway >= approximate land 
rollout distance for type of landing (ft) (able to stop before end of 
runway) 

2000 

6000 


* Text in bold indicates parameters specified under “Default Threshold”. 
** GA thresholds have not been verified through testing. 
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Table A2. Ownship Takeoff Mode Criteria & Default Thresholds 


Takeoff Mode Criteria - Ownship 

Code 

Description * 

Default Threshold 

GA** 

Non-GA 

FI 

EPR mode set (true/false) 

NA 

NA 

F2 

Auto throttle engaged (true/false) 

NA 

NA 

F3 

Throttle position >= takeoff throttle position (degrees)fnon-GA) 

- 

90 

F4 

Throttle position is at full forward GA 

NA 

- 

F5 

Track acceleration > 0.0G 

NA 

NA 

F6 

Track acceleration >= 0.1G 

NA 

NA 

F7 

Track acceleration > 0.1G 

NA 

NA 

F8 

Track acceleration >= takeoff acceleration (G) 

0.2 

0.2 


Table A3. Traffic Operational State Criteria & Default Thresholds 


Operational State Criteria - Traffic 

Code 

Description * 

Default Threshold 

GA** 

Non-GA 

I 

Altitude above ground level (ft) <= 0 

NA 

NA 

J 

Aircraft is on the runway 

NA 

NA 

K 

True heading differs from runway zone true heading <= heading 
tolerance (degrees) 

10 

10 

L 

Ground speed <= taxi high speed (knots) 

20 

40 

M 

Ground speed >= taxi low speed (knots) 

4 

4 

N 

Ground speed > minimum start takeoff speed for traffic (knots) 

15 

15 

O 

Acceleration >= minimum start takeoff acceleration for traffic 
(knots/sec) 

3 

3 

P 

Acceleration > minimum takeoff acceleration for traffic 
(knots/sec) 

0.1 

0.1 

Q 

Vertical speed > minimum climb -out vertical speed for traffic 
(ft/min) 

60 

60 

R 

Distance from traffic position to end of runway >= maximum 
traffic rollout distance (ft) (able to stop before end of runway) 

2000 

6000 
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Table A4. Operational State Definitions 


Operational State 

Ownship Criteria 

Traffic Criteria 

taxi/stationary 
(on or near 
runway) 

A and B and C and 

((not D) or (not E) or (not F)) 

I and L and M and J and K and 
((not N) or (not O)) 

I and L and M and ((not J) or (not K)) 

I and L and (not M) 

A and B and 

(not C) and ((not D) or (not E)) 

I and (not L) and ((not J) or (not K)) 

pre-takeoff 

A and B and C and D and E and F 

NA 

takeoff roll 

A and B and (not C) and D and E and F 

I and L and M and J and K and N and 0 

I and (not L) and J and K and P 

climb-out 

((not A) or (not B)) and E and G 

(not L) and K and Q 

((not A) or (not B)) and E and 
(not G) and (not H) 

(not L) and K and (not Q) and (not R) 

approach 

((not A) or (not B)) and E and 
(not G) and H 

(not L) and K and (not Q) and R 

rollout 

A and B and (not C) and D and E and 
(not F) 

I and (not L) and J and K and (not P) 

fly-thru RI zone 

((not A) or (not B)) and (not E) 

(not L) and (not K) 
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Appendix B - RSM Scenarios and Alert Criteria 


This appendix describes in detail the scenarios, alert criteria, and thresholds used by RSM to issue 
caution alerts and warning alerts (see Sections 3.1.1 and 3.1.2). The alert criteria and default thresholds 
are listed separately for conflicts on single runways (Table Bl) and conflicts on intersecting runways or 
intersecting flight paths (Table B2). An intersecting flight path occurs when runway incursion (RI) zones 
intersect before or beyond the runway boundary (see Section 3.3). The default thresholds for alert criteria 
are implemented as parameters that are contained in software configuration files. The default values for 
warning thresholds were determined through simulation and flight testing, but can be modified as 
required based on future research. The default values for caution thresholds have undergone simulation 
evaluation, but are subject to change based on future research and testing. Previous testing [Jones, 2002 
and Jones and Prinzel, 2006] revealed that cautions were only effective/desirable when the ownship was 
in the approach state, or when the ownship was in position and hold and the traffic was approaching the 
same runway. Therefore, cautions are only implemented for two types of scenarios: (i) ownship state is 
approach, or (ii) ownship state is taxi or pre-takeoff, and traffic state is approach. 

For RSM criteria which specify a distance threshold, the distance is measured from the aircraft center 
of gravity (CG). Distance between ownship and traffic is measured from the ownship CG to the traffic 
CG. 

The tables B3 - B9 define the scenarios for each combination of ownship and traffic states for both 
single and intersecting runway/flight path conditions and list the alert criteria associated with each 
scenario from the appropriate criteria table (Bl or B2). RSM detects and issues alerts for runway 
conflicts only when both the ownship aircraft and traffic are inside RI zones and below the zone altitude. 
For single runway scenarios, traffic is defined as other aircraft, vehicles, obstacles or equipment inside the 
same RI zone as the ownship aircraft. For intersecting zone scenarios, traffic is defined as other aircraft 
departing, arriving, or taxiing inside the RI zone that intersects the ownship RI zone. Traffic position and 
other traffic data must be available via data link to the ownship aircraft (see Section 4.2). 
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Table Bl. Alert Criteria & Default Thresholds for Single Runway Scenarios 


Alert Criteria - Single Runway Scenarios 
(Assumes Ownship and Traffic are inside the same runway incursion zone) 





Default Threshold 




GA 

Non-GA 

Code 

Description * 

CA** 

WA+ 

CA** 

WA+ 

A 

Alert immediately at any distance 

NA 

NA 

NA 

NA 

B 

O/T < minimum horizontal separation threshold (ft) 

6000 

4500 

8000 

6000 

C 

O/T < close horizontal separation (ft) (lower separation 

threshold for some scenarios) 

** 

700 

** 

700 

D 

Distance from runway threshold of aircraft taxiing or stopped on 
runway is < approximate land rollout distance for type of landing 
aircraft (ft) 

2000 

2000 

6000 

6000 

E 

Aircraft rolling out not able to stop before aircraft taxiing or 
stopped on runway 

** 

NA 

** 

NA 

Fa 

Ownship distance to runway threshold or traffic position < 

Per 

Per 

Per 

Per 


airborne approach alert distance (ft) 

own 

own 

own 

own 


(airborne alert distance based on approximate ownship landing 

landing 

landing 

landing 

landing 


speed, e.g., B-757 4400 ft for warning, 8000 ft for caution) 

speed 

speed 

speed 

speed 

Fc 

Ownship distance to runway threshold or traffic position < 

Per 

Per 

Per 

Per 


airborne climb-out alert distance (ft) 

own 

own 

own 

own 


(airborne alert distance based on approximate ownship climbing 

landing 

landing 

landing 

landing 


speed, e.g., B-757 6000 ft for warning, 8000 ft for caution) 

speed 

speed 

speed 

speed 

G 

Stationary aircraft time to exit runway < alert time threshold 
(sec) 

NA 

30 

NA 

30 

H 

Ownship distance to traffic position < 2.0 times the minimum 
horizontal separation threshold (ft) 

(increased horizontal separation required for some scenarios) 

12000 

9000 

16000 

12000 

I 

Arriving aircraft past the runway threshold 

NA 

NA 

NA 

NA 

J 

O/T current or projected closest altitude separation < minimum 
air-to-air altitude separation (ft) 

1000 

850 

1000 

850 

K 

O/T current or projected closest vertical separation < minimum 

air-to-ground vertical separation when one aircraft is on the 
ground (ft) 

** 

400 

** 

400 


* Text in bold indicates parameters specified under “Default Threshold”. 

** Caution alert (CA) thresholds will only be applied for single runway scenarios of taxi/approach, pre- 
takeoff/approach, or any ownship approach scenario. 

+ WA = warning alert 
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Table B2. Alert Criteria & Default Thresholds for Intersecting Runway/Flight Path Scenario 


Alert Criteria - Intersecting Runway and Flight Path Scenarios 


(Assumes Ownship and Traffic are inside intersecting RI zones and not past the zone intersection) 


Code 

Description * 

Default Threshold 

GA 

Non-GA 

CA** 

WA+ 

CA** 

WA+ 

L 

Alert immediately at any distance 

NA 

NA 

NA 

NA 

M 

Current O/T difference in separation from intersection is < min 

separation threshold (ft) 

6000 

4500 

8000 

6000 

N 

Current O/T difference in separation from intersection is < 0.5 

times the min separation (ft) 

3000 

2250 

4000 

3000 

O 

Projected O/T closest separation at the intersection is < 

minimum separation threshold (ft) 

6000 

4500 

8000 

6000 

P 

Projected O/T closest separation at the intersection is < 0.5 

times the min separation (ft) 

3000 

2250 

4000 

3000 

Qa 

Ownship distance to runway threshold < airborne approach 
alert distance (ft) 

(airborne alert distance based on approximate ownship landing 
speed, e.g., B-757 4400 ft for warning, 8000 ft for caution) 

Per 

own 

landing 

speed 

Per 

own 

landing 

speed 

Per 

own 

landing 

speed 

Per 

own 

landing 

speed 

Ra 

Ownship distance to intersection < airborne approach alert 
distance (ft) 

(airborne alert distance based on approximate ownship landing 
speed, e.g., B-757 4400 ft for warning, 8000 ft for caution) 

Per 

own 

landing 

speed 

Per 

own 

landing 

speed 

Per 

own 

landing 

speed 

Per 

own 

landing 

speed 

Rc 

Ownship distance to intersection < airborne climb-out 
distance (ft) 

(airborne alert distance based on approximate ownship climbing 
speed, e.g., B-757 6000 ft for warning, 8000 ft for caution) 

Per 

own 

landing 

speed 

Per 

own 

landing 

speed 

Per 

own 

landing 

speed 

Per 

own 

landing 

speed 

S 

Distance from touchdown to intersection for landing aircraft is < 

approximate land rollout distance for type aircraft (ft) 

2000 

2000 

6000 

6000 

T 

Aircraft rolling out is not able to stop before intersection 

NA 

NA 

NA 

NA 

U 

Aircraft rolling out is < close distance to the intersection (ft) 

700 

700 

700 

700 

V 

O/T current or projected closest air-to-air altitude separation is < 

minimum airborne altitude separation threshold (ft) 

1000 

850 

1000 

850 

w 

O/T current or projected closest air-to-ground vertical separation 

is < minimum air-ground separation threshold (ft) 

400 

400 

400 

400 

X 

O/T current or projected difference in separation from 
intersection is < close distance to the intersection (ft) 

700 

700 

700 

700 

Y 

O/T current or projected difference in separation from 
intersection is < 1.5 times the close distance to the 
intersection (ft) 

1050 

1050 

1050 

1050 


* Text in bold indicates parameters specified under “Default Threshold”. 

** Caution alert (CA) thresholds will only be applied for intersecting runway scenarios in which the ownship state is 
approach. 

+ WA = warning alert 
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Table B3. Scenario Conditions and Alert Criteria - Ownship in Taxi State 


Ownship (0) State - Taxi On or Near Runway (Inside RI zone) 

Traffic (T) State 

Single Runway 

Intersecting Runways and RI Zones 

Scenario Conditions 

Alert Criteria 

Scenario Conditions 

Alert Criteria 

taxi/stationary 

Disabled for RSM scenarios 
(Taxi conflicts are 
monitored by TCM) 

— 

Not defined for 
ownship taxi 
scenarios 

— 

pre-takeofl' 

NA (Traffic pre -takeoff 
state not avail in current 
version) 

— 

— 

— 

takeoff roll 

0 in path of T and closing 

A 

— 

— 

climb-out 

O Taxi /T Closing 
O Stationary / T Closing 

B and K 
K 

— 

— 

approach 

O/T Closing 

(B or G) and D 
(warning) 

D (caution)* 

— 

— 

rollout 

O/T Closing 

(E or C) 

— 

— 

fly-thru RI zone 

Not defined; alerts not 
issued 

— 

— 

— 


* Criteria B and G are not applied for cautions in this scenario. 


41 






















Table B4. Scenario Conditions and Alert Criteria - Ownship in Pre -takeoff State 


Ownship (0) State - Pre -takeoff 

Traffic (T) State 

Single Runway 

Intersecting Runways and RI Zones 

Scenario Conditions 

Alert Criteria 

Scenario Conditions 

Alert Criteria 

taxi/stationary 

T in path of O 

A 

Not defined for traffic taxi 
scenarios 

— 

pre-takeoff 

NA (Traffic pre-takeoff 
state not avail in current 
version) 

— 

— 

— 

takeoff roll 

T in path of O 

A 

Intersect before end of 0 
runway 

L 

T behind 0 and closing 

A 

Intersect beyond end of 0 
runway 

N or O 

climb -out 

O/T same heading & 
runway 

B and K 

All conditions 

W and (N or 
O) 

O/T head-on, opposite 
runways 

K 

approach 

O/T same heading & 
runway and T behind O 

B or G 
(warning) 

A (caution)* 

Intersect before end of 0 
runway 

s 

O/T same heading & 
runway and T in path of 0 

B 

(warning)* 

Intersect beyond end of 0 
runway 


O/T head-on, opposite 
runways 

B or G 
(warning) 

A (caution)* 

rollout 

T in path of O 

A 

Intersect before end of 0 
runway 

T or ((not T) 
and U) 

T behind 0 and closing 

B 

Intersect beyond end of 0 
runway 

— 

fly-thru RI zone 

Closing or T in path of 0 

C and K 

Not defined for traffic fly- 
thru scenarios 

— 


* Criteria B and G are not applied for cautions in this scenario. 
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Table B5. Scenario Conditions and Alert Criteria - Ownship in Takeoff roll State 


Ownship (0) State - Tal 

ceoff roll 

Traffic (T) State 

Single Runway 

Intersecting Runways and RI Zones 

Scenario Conditions 

Alert Criteria 

Scenario Conditions 

Alert Criteria 

taxi/stationary 
(on or near 
runway) 

T in path of 0 and closing 

A 

Not defined for traffic taxi 
scenarios 

— 

pre -takeoff 

NA (Traffic pre -takeoff 
state not avail in current 
version) 

— 

— 

— 

takeoff roll 

0/T same heading & 
runway 

B 

O able to abort takeoff and 
intersect before end of 0 
runway 

L 

O able to abort takeoff and 
intersect beyond end of O 
runway 

N or P 

O/T head-on, opposite 
runways 

A 

O not able to abort takeoff 

X 

climb-out 

O/T same heading & 
runway 

B 

O able to abort takeoff 

M or O 

O/T head-on, opposite 
runways 

A 

O not able to abort takeoff 

X 

approach 

O/T same heading & 
runway and T behind O 

B 

O able to abort takeoff and 
intersect before end of 0 
runway 

s 

O/T same heading & 
runway and T in path of 0 

A 

O not able to abort takeoff 
and intersect before end of 
O runway 

S and Y 

O/T head-on, opposite 
runways 

A 

Intersect beyond end of 0 
runway 

— 

rollout 

O/T same heading & 
runway and T in path of 0 

A 

O able to abort takeoff and 
intersect before end of 0 
runway 

T or 

((not T) and U) 

O/T same heading & 
runway and T behind O 
and closing 

B 

O not able to abort takeoff 
and intersect before end of 
O runway 

(T and Y) or 
((not T) and U) 

O/T head-on, opposite 
runways 

A 

Intersect beyond end of 0 
runway 

— 

fly-thru RI zone 

Closing or T in path of 0 

C and K 

Not defined for traffic fly- 
thru scenarios 

— 
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Table B6. Scenario Conditions and Alert Criteria - Ownship in Climb-out State 


Ownship (0) State - Climb-out 

Traffic (T) State 

Single Runway 

Intersecting Runways and RI Zones 

Scenario Conditions 

Alert Criteria 

Scenario Conditions 

Alert Criteria 

taxi/stationary 

O/T closing 

K and Fc 

Not defined for traffic 
taxi scenarios 

— 

pre-takeoff 

NA (Traffic pre-takeoff 
state not avail in current 
version) 

— 

— 

— 

takeoff roll 

O/T same heading & 
runway 

B 

All conditions 

W and Rc 
and (N or P) 

O/T head-on, opposite 
runways 

A 

climb -out 

O/T same heading & 
runway 

B 

All conditions 

Rc and 
(N or P) 

O/T head-on, opposite 
runways 

(I or H) 

approach 

O/T same heading & 
runway 

B 

All conditions 

V and S and 
Rc and 
(N or P) 

O/T head-on, opposite 
runways 

J and (I or H) 

rollout 

O/T same heading & 
runway and T in path of 0 

K and B 

All conditions 

Wand 
(N or P) and 
Rc and 
(T or U) 

O/T same heading & 
runway and T behind O 
and closing 

K and B 

O/T head-on, opposite 
runways 

K and (I or B) 

fly-thru RI zone 

O/T closing or 
T in path of O 

B 

Not defined for traffic 
fly-thru scenarios 

— 
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Table B7. Scenario Conditions and Alert Criteria - Ownship in Approach State 


Ownship (0) State - Approach 

Traffic (T) State 

Single Runway 

Intersecting Runways and RI Zones 

Scenario Conditions 

Alert Criteria 

Scenario Conditions 

Alert Criteria 

taxi/stationary 

Closing 

D and Fa 

Not defined for traffic 
taxi scenarios 

— 

pre-takeoff 

NA (Traffic pre -takeoff 
state not avail in current 
version) 

— 

— 

— 

takeoff roll 

0/T same heading & 
runway 

B 

All conditions 

S and (N or P) 
and 

(Qa or Ra) 

0/T head-on, opposite 
runways 

A 

climb-out 

0/T same heading & 
runway 

B 

All conditions 

S and V and 
P and 
(Qa or Ra) 

0/T head-on, opposite 
runways 

J and (H or I) 

approach 

0/T same heading & 
runway 

B 

All conditions 

S and (N or P) 
and 

(Qa or Ra) 

0/T head-on, opposite 
runways 

(H or I) 

rollout 

0/T same heading & 
runway 

B 

All conditions 

S and (T or U) 
and 

(Qa or Ra) 

0/T head-on, opposite 
runways 

A 

fly-thru RI zone 

O/T closing or 
T in path of O 

B 

Not defined for traffic 
fly-thru scenarios 

— 
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Table B8. Scenario Conditions and Alert Criteria - Ownship in Rollout State 


Ownship (0) State - Rollout 

Traffic (T) State 

Single Runway 

Intersecting Runways and RI Zones 

Scenario Conditions 

Alert Criteria 

Scenario Conditions 

Alert Criteria 

taxi/stationary 

O/T closing 

E or C 

Not defined for 
traffic taxi scenarios 

— 

pre -takeoff 

NA (Traffic pre -takeoff 
state not avail in current 
version) 

— 

— 

— 

takeoff roll 

O/T same heading & 
runway and T ahead of O 

B 

All conditions 

(T or U) 

O/T same heading & 
runway and T behind O 

A 

O/T head-on and opposite 
runways 

A 

climb-out 

O/T same heading & 
runway and T behind O 

K and B 

All conditions 

W and (M or 
O) and 
(T or U) 

O/T same heading & 
runway and T ahead of O 

K and B 

O/T head-on, opposite 
runways 

K and (I or B) 

approach 

O/T same heading & 
runway (T behind or 
ahead) 

B 

All conditions 

S and (T or U) 

O/T head-on, opposite 
runways 

A 

rollout 

O/T same heading & 
runway 

B 

All conditions 

(T or U) 

O/T head-on, opposite 
runways 

A 

fly-thru RI zone 

O/T closing or 
T in path of O 

C and K 

Not defined for 
traffic fly-thru 
scenarios 

— 
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Table B9. Scenario Conditions and Alert Criteria - Ownship in Fly-thru RI Zone State 


Ownship (0) State - Fly-thru RI Zone 

Traffic (T) State 

Single Runway 

Intersecting Runways and RI Zones 

Scenario Conditions 

Alert Criteria 

Scenario Conditions 

Alert Criteria 

taxi/stationary 

Incursion scenario not 
defined; alerts not issued 

— 

Not defined for ownship 
fly-thru scenarios 

— 

pre-takeoff 

NA (Traffic pre -takeoff 
state not avail in current 
version) 

— 

— 

— 

takeoff roll 

Closing or 0 in T path 

C and K 

— 

— 

climb -out 

Closing or 0 in T path 

B 

— 

— 

approach 

Closing or 0 in T path 

B 

— 

— 

rollout 

Closing or 0 in T path 

C and K 

— 

— 

fly-thru RI zone 

Incursion scenario not 
defined; alerts not issued 

— 

— 

— 
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Appendix C - RSM Scenarios and SURF IA Indication Criteria 


In parallel with CAAT, the RTCA SC-186 WG1 subcommittee for surface indication and alerting 
(SURF IA) has defined criteria to determine whether a potential conflict exists between an ownship and 
traffic aircraft [RTCA, 2010b]. SURF IA is only concerned with runway scenarios, and is not relevant to 
low altitude or taxi scenarios. Similar to CAAT, SURF IA identifies operational states for each aircraft. 
Resembling CAAT, for each possible combination of ownship state and traffic state, SURF IA defines a 
set of criteria to determine whether an alert should be issued. SURF IA also classifies alerts to be either 
Cautions or Warnings, as does ATCAM. SURF IA defines alerts for "non-normal operational situations 
where collision hazard exists or a collision appears imminent". ATCAM does not implement alerts as 
defined by SURF IA, but instead uses the RSM algorithm defined previously. 

In addition to alerts, SURF IA also specifies indications, which are defined for "normal operational 
situations where collision hazard exists". In other words, indications are less serious than alerts. SURF 
IA classifies indications to be either Traffic Indications (TI) or Runway Status Indications (RSI). 

RSM has been extended to implement SURF IA indications. RSM operational states are converted 
into SURF IA states, as defined in Table A-l of reference RTCA 2010b. This conversion is described in 
Table Cl below. RSM will issue indications prior to alerts if the criteria in Table A-2 of reference RTCA 
2010b are met. However, alerts have priority over indications and will be issued instead of indications if 
the alert criteria is met. 


Table Cl . ATCAM-to-SURF IA State Mapping 


ATCAM States 

Mapping Conditions 

SURF IA States 

hold short* 

Stopped outside RI zone within 500 
ft. of centerline, facing runway 

I. Taxiing on taxiway toward hold 
line or stopped at hold line 

Taxiing outside RI zone beyond 
look-ahead distance, within 500 ft. 
of centerline, facing runway 

taxi/stationary 

Outside RI zone, within look-ahead 
distance 

I. Taxiing on taxiway toward hold 
line or stopped at hold line 

Inside RI zone, heading differs from 
runway heading by more than 10 
degrees 

II. Entering / Crossing / Exiting 

Inside RI zone, heading within 10 
degrees of runway heading 

VI. Stopped or taxiing along runway 

pre-takeoff 


VI. Stopped or taxiing along runway 

takeoff roll 


III. Takeoff 

climb -out 


0. Unknown 

approach 


IV. Approach 

rollout 


V. After Landing 

fly-thru 


0. Unknown 


* Hold short is a new RSM state, created to support SURF IA state I. A new state is necessary because 
RSM currently does not consider stationary aircraft at the hold line to be traffic; but such aircraft are 
candidates for indications. This state is only relevant when determining indications, and does not affect 
alert calculations. 
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RSM can be expected to issue indications according to SURF IA specifications, except in the 
following cases: 

• If RSM issues an alert for a case in which SURF IA does not issue an alert, then RSM will not 
issue any SURF IA indications, because the alert takes precedence. 

• RSM will not classify an aircraft to be in approach state until it reaches the extended runway 
zone, and will not issue indications for that aircraft outside the extended zone. SURF IA defines 
the approach state to begin within three nautical miles, once the aircraft descends below one 
thousand feet. Consequently, SURF IA may issue approach indications earlier than RSM. 
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Appendix D - Flight Data Requirements 

This appendix lists the flight data that is currently used by the ATCAM software. Table D1 lists the 
ownship data, while Table D2 lists the traffic data. Note that the throttle position or power lever angle is 
assumed to be available to indicate forward thrust (with thrust reverser data available as well) for a 
‘commercial transport aircraft’ (i.e., “non-GA”), whereas for general aviation aircraft, the throttle position 
ranging between 0 (full closed) and 1 (full open) is used to imply forward thrust (i.e., “GA”). 


Table D 1 . Ownship Data Parameters 


DESCRIPTION 

BINARY 

RANGE 

UNITS 

POSITIVE 

REFERENCE 

MINIMUM 

UPDATE 

RATE 

Update counter 


NA 

Always positive 

10 HZ 

Standard time in GMT 

0 to 86,400 

Sec 

Seconds from midnight 

10 HZ 

Scaled GPS/INS blended latitude 

+/-90 

Deg 

North from 0 

10 HZ 

Scaled GPS/INS blended long 

+/-180 

Deg 

East from 0 

10 HZ 

GPS/INS blended altitude-feet MSL 

+/-32J68 

Feet 

Above touchdown 

10 HZ 

Geoid separation corrected hybrid GPS 
altitude 

+/-32,768 

Feet 

Above touchdown 

10 HZ 

Corrected barometric altitude - 4 sources 

+/-32J68 

Feet 

Above sea level 

10 HZ 

Radar altitude 

+/- 32,768 

Feet 

Above touchdown 

10 HZ 

Ground speed 

0 - 4096 

Knots 

Always positive 

10 HZ 

Vertical speed 

+/-19.384 

Ft/Min 

Up 

10 HZ 

True heading 

+/-180 

Deg 

CW from North 

10 HZ 

Yaw rate 

+/-128 

Deg/Sec 

Nose right 

10 HZ 

Track angle (true) 

+/-180 

Deg 

CW from North 

10 HZ 

Along track acceleration 

+/- 4 

G's 

Forward 

10 HZ 

Throttle position/power lever angle - left 
(non-GA) 

+/-180 

Deg 

Forward thrust 

10 HZ 

Throttle position/power lever angle - right 
(non-GA) 

+/-180 

Deg 

Forward thrust 

10 HZ 

Throttle position (GA) 

Discrete 

NA 

1 = Full open 

10 HZ 

Reverser isolation valves 

Discrete 

NA 

1 =Re verse thrust 

10 HZ 

Air ground discrete 

Discrete 

NA 

l=Main gear on ground 

10 HZ 

Nose wheel squat 

Discrete 

NA 

l=Nose wheel on ground 

10 HZ 

Go around discrete 

Discrete 

NA 

l=Go around engaged 

10 HZ 

Auto-throttle engaged 

Discrete 

NA 

1 =Engaged 

10 HZ 

Decision speed 

0-512 

Knots 

Always positive 

10 HZ 

GPS hybrid position status 

Discretes 

NA 

0=Good 

10 HZ 
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Table D2. Traffic Data Parameters 


DESCRIPTION 

BINARY 

RANGE 

UNITS 

POSITIVE 

REFERENCE 

UPDATE 

RATE 

# Traffic/intruders 

0-64 

NA 

Always positive 

1-2 HZ 

Traffic update counter 


NA 

Always positive 

1-2 HZ 

24 bit ICAO address or unique intruder id 

0-32 

NA 

NA 

1-2 HZ 

Intruder flight or tail number 

Character field 

NA 

NA 

1-2 HZ 

A/C category (A380, B757, etc.) 

0-7 

NA 

NA 

1-2 HZ 

A/C type fif known) 

Character field 

NA 

NA 

1-2 HZ 

Latitude 

+/-90 

Deg 

North from 0 

1-2 HZ 

Longitude 

+/-180 

Deg 

East from 0 

1-2 HZ 

Altitude MSL 

+/-32J68 

Feet 

Above mean sea level 

1-2 HZ 

Radar altimeter 

+/-32J68 

Feet 

Above touchdown 

1-2 HZ 

Ground speed 

0-32,768 

Knots 

Always positive 

1-2 HZ 

True track (airborne) or heading (on ground) 

+/-180 

Deg 

CW from North 

1-2 HZ 

Vertical speed 

+/-19.384 

Ft/Min 

Up 

1-2 HZ 

Track acceleration 

+ 1-4 

G’s 

Forward 

1-2 HZ 

Slant range 


NM 

Always positive 

1-2 HZ 

Bearing 

+/-180 

Deg 

CW from ownship 

1-2 HZ 

Relative altitude 

+/-32768 

Feet 

Above ownship 

1-2 HZ 

Traffic acquisition in msec GMT 

0 to 86,400,000 

Msec 

Always positive 

1-2 HZ 
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Appendix E - Surveillance Discussion 

E.l Surveillance Performance 

Requirements for ground-based surveillance systems have been proposed. As mentioned above, 
ICAO proposed operational requirements for A-SMGCS, which includes surveillance performance 
requirements [ICAO, 1997]. A prototype A-SMGCS architecture was evaluated during a flight test at the 
Atlanta Hartsfield International Airport [Jones and Young, 1998] and observed performance was 
compared against the A-SMGCS requirements [Young, 1998]. 

More recently, the European Organization for Civil Aviation Equipment (EUROCAE) has proposed 
surveillance performance requirements for a Level 2 A-SMGCS that will be expected to monitor the 
airport surface and provide alerts to users when hazardous situations occur, such as runway incursions 
[EUROCAE, 2007], These requirements are listed in Table El . 

The FAA is in the process of deploying ADS-B throughout the NAS. A final rule [FAA, 2010] has 
been enacted to specify ADS-B Out performance requirements necessary to support ATC service. 
Although the FAA is not mandating ADS-B In at this time, the final rule includes a discussion of 
potential ADS-B In applications and accuracy requirements. The Notice of Proposed Rulemaking 
(NPRM) [FAA, 2007] had proposed that a horizontal accuracy of 30 meters (98.4 feet) and a vertical 
accuracy of 45 meters (147.6 feet) would be sufficient to enable certain applications on the airport 
surface, such as traffic alerting, however, the final rule only requires a horizontal accuracy of 0.05 nm 
(92.6 meters or 303.8 feet) and has removed the vertical accuracy and integrity requirement. The RTCA 
SC- 186 WG1 subcommittee for surface indication and alerting (SURF IA) has conducted analyses and 
requires a minimum of a Navigation Accuracy Category position (NACp) of 9 for the SURF IA 
application [RTCA, 2010b] (see Table E2), which corresponds to the position accuracy proposed in the 
NPRM. Unfortunately, the final rule requires position accuracy of traffic data corresponding to a NACp 
of 8, which may be insufficient for CD&R applications. More analysis is needed to determine whether 
these proposed accuracies are really sufficient for conflict detection. 


Table El. EUROCAE A-SMGCS Surveillance Performance Requirements 


Performance Parameter 

Level 2 System Requirement 

Probability of target detection 

> 99.9% on maneuvering area 
>98% on apron 

Probability of false target detection 

< 1 0 3 per report 

Probability of identification 

> 99.9% on maneuvering area 
>98% on apron 

Probability of false identification 

< 1 0 3 per report 

Reported position accuracy 

< 7.5 meters (95%) on maneuvering area 
<12 meters (95%) on apron 

Reported velocity accuracy 

Speed < 5 meters/second, Direction - 

consistent with use in alerting algorithms 

Target report update rate 

At least 1 per second 

Position renewal time out period 

< 4 seconds 

Identification renewal time out period 

< 20 seconds 

Track continuity 

> 99.8% on maneuvering area 
>98% on apron 

Target report position resolution 

<1 meter 

Target report velocity resolution 

<0.25 meter/second 

Target report time resolution 

< 0. 1 second 
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Table E2. SURF IA Surveillance Performance Requirements 


Performance Parameter 

Requirement 

Traffic horizontal position accuracy 

Distance from runway 
Shoulder to hold line (m) NACp 

20-25 11 

30 - 60 10 

65 - 100 9 

95% containment radius 

Ownship and traffic geometric altitude 

45m, 95% 

Ownship and traffic velocity 

10 m per second 

Vehicle horizontal position accuracy 

10 m, 95% containment 

Ownship and traffic integrity level 

Indication -lx 10-4 per hour 
Caution -lx 10-4 per hour 
Warning -lx 10-5 per hour 


E.2 Intent Data 

ADS-B provides a minimal set of data for aiiport traffic. Historically, the RSM algorithm has had 
good results in computing traffic states, utilizing the currently available data from ADS-B, however, 
knowledge of traffic intent could potentially provide a more accurate assessment of traffic state and result 
in more precise conflict detection with reduced missed, and nuisance alerts. Some intent data currently 
specified for ADS-B involve intent to change trajectory at a particular position. However, the type of 
intent data that may improve the performance of the conflict detection function in the ATMA is related to 
operations on or near the airport surface. 

Ownship states can be computed accurately because the data to indicate “intent” to takeoff, “intent” 
to land, etc., is available from the ship’s flight computers. Some examples of these data sources might 
include: 

• Takeoff intent - on the runway, lined up with runway heading and Engine Pressure Ratio (EPR) 
button or Auto-throttle button pushed, throttle position. 

• Intent to land - Auto-land engaged, lined up with runway and descending, ILS tuned and aircraft 
following localizer and glideslope, landing configuration and airspeed. 

However, these intent data are not available for traffic. With the increase in capacity envisioned by 
NextGen, traffic will be more densely spaced making the need for knowledge of traffic intent even more 
critical. 

The following traffic intent data/information could potentially enable more effective, timely, and 
error free CD&R in the ATMA. More analysis is necessary to determine the potential benefits of utilizing 
this data/information. 

• Takeoff mode - Determining when traffic is actually taking off can currently be determined by 
monitoring ground speed. Knowing that the pilot has taken the runway and has engaged the EPR 
mode or Auto throttle mode, for example, would indicate takeoff intent as well as knowing throttle 
position (advanced full forward) in lesser equipped aircraft. 

• Go Around mode - Knowing when traffic is aborting a landing can currently be determined by 
noting that the aircraft is climbing and accelerating. A more timely means would be to transmit 
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when the go around is initiated (go around button pressed or throttles advanced and aircraft 
configured for climbing). 

• Rejected Takeojf mode - Knowing when an aircraft aborts takeoff can eventually be determined by 
observing the traffic’s greatly reduced speed and either stopping on or exiting the runway. The 
ability to know if the power goes to idle (throttle position), brakes are pressed and/or thrust 
reversers are used could result in a more effective means of determining if a rejected takeoff 
occurred. 

• Land and Hold Short Operations (LAHSO) - Knowing intent to follow LAHSO operations at 
airports like ORD might prevent nuisance runway incursion alerts in an intersecting runway 
situation. The logic would be similar to the rejected takeoff criteria above for determining intent to 
stop. Knowledge of intent to LAHSO could be obtained via pilot entry or, in the absence of such an 
entry, via broadcast of ATC instructions (see below). 

• Termination of taxi - Knowing that the traffic that could become a conflict is aware and braking 
might allow the CD&R algorithms to delay alerting to prevent nuisance alerts in cases where the 
errant traffic’s nose barely passed the hold short line or the errant traffic could stop before 
becoming dangerously close to another aircraft on the surface. 

• Air-ground - Knowing whether traffic is in the air or on the ground is critical for ATMA CD&R. 
Airborne ADS-B messages are needed for runway and low altitude CD&R because the message 
contains altitude data. When an aircraft is determined to be on the ground, ADS-B transmissions 
will contain surface message content (with no altitude data) instead of airborne message content. If 
surface ADS-B messages are transmitted prematurely, runway and low altitude CD&R could be 
affected. Since surface position messages are transmitted less frequently than airborne position 
messages, valuable position data required when the aircraft is indeed airborne with a rapid closure 
rate is unavailable, possibly leading to an avoidable collision. It is not clear that the current method 
of switching between airborne and surface ADS-B messages will be sufficient for ATMA CD&R. 
Aircraft with air-ground detection would switch at the proper time. All others would switch based 
on the presence or absence of airspeed, ground speed, and radar altitude which will either cause an 
early or delayed switch between airborne position messages and surface position messages. 
Knowing precisely when traffic is on the ground based on weight on wheels or nose wheel squat 
could potentially resolve this ambiguity. 

• Air Traffic Control Instructions - Knowledge of other traffic’s clearances (e.g., “cleared for 
takeoff’, cleared to land”, “land and hold short”) for operations in the ATMA could potentially 
increase safety and prevent conflicts and collisions through awareness of the intentions of other 
traffic. Awareness of traffic’s intended taxi path and hold short clearances may also reduce 
conflicts at taxiway and runway intersections. Taxi awareness and conflict prevention/detection 
can be further refined in the NextGen environment with knowledge of traffic’s 4-D taxi path and 
required times of arrival at intersections. 

E.3 ADS-B Altitude Data 

An area of concern for CD&R in the ATMA is the granularity of all ADS-B reported altitudes. The 
source for ADS-B altitude is currently either Global Navigation Satellite System (GNSS) or barometric 
altitude reported to the nearest 100 feet or 25 feet [RTCA, 2009]. These accuracies are sufficient for 
aircraft that are airborne and not near the surface (above 1000 feet AGL). However, since altitude 
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changes rapidly during takeoff and departure, these accuracies may not be good enough for the current 
implementation of an algorithm such as ATMA CD&R. The current implementation uses three separate 
algorithms with very different capabilities operating to cover all flight realms and altitude is a key trigger 
for switching between the algorithms. This issue has not, at this time, been rigorously evaluated. 

Sources of error for barometric altitude reporting include instrument calibration, rounding altitude to 
the nearest 25 + 12.5 feet or 100 feet + 50 feet, and incorrect barometric pressure setting. An incorrect 
setting of 0.5 inches Mercury could cause the altitude report to be 500 feet higher or lower than the actual 
barometric altitude. GNSS position data also has the greatest error in its vertical measurements, i.e., the 
height above the ellipsoid. As a result, aircraft could be mistaken for being on the ground while airborne 
or vice versa, which could cause CD&R algorithms, such as ATCAM, to incorrectly determine the traffic 
operational states. (See Section 5.4.4). Further testing is needed to determine the effects of altitude 
variance on CD&R algorithms, and in what ways algorithms need to account for such variance. 

ADS-B altitude accuracy could be improved if radio altitude were used in lieu of GNSS or barometric 
altitude when the aircraft is within 1000 feet of the airport surface. Many radar altitudes provide radio 
altitude accuracy to within 2 feet. (Unfortunately, radar altitude is not required on most aircraft.) 
Barometric and GNSS altitudes are encoded to the nearest 25 feet or 100 feet within the airborne position 
message format to conserve the number of bits utilized in data transmission while still providing suitable 
altitude accuracy at the higher altitudes. Since the range of values for the radio altitude are capped, 
usually to 2500 feet, the space allocated within the ADS-B airborne message format can represent the 
radio altitude to the nearest foot. Using radio altitude in lieu of GNSS or barometric altitude to represent 
a much more accurate value for altitude AGL, would enable ATMA CD&R algorithms to make more 
accurate aircraft state decisions. 

Another area of concern is the transition between ADS-B airborne and surface messages (see 
previous section). Radio altitude is used as the criteria to switch between airborne and surface messages. 
Aircraft with a radio altitude of 50 feet or less are considered to be on the ground when ground speed is 
100 knots or less [RTCA, 2009]. Since ADS-B surface position messages do not include altitude, the 
transition to surface messages at 50 feet AGL or greater due to the errors mentioned above would cause 
the loss of altitude reports before touchdown, which could cause nuisance CD&R alerts. Using alternate 
criteria, such as weight-on-wheels or nose wheel squat for those aircraft that provide that information, 
would ensure the switch to surface position message transmission would occur when the aircraft is on the 
ground. 

Further research is needed to determine the effect of ADS-B altitude accuracy and surface message 
reporting on ATMA CD&R. 
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